* c60b1f4 2020-06-26 | e1000: Do not perform reset in reset_task if we are already down (#148) (HEAD -> master, origin/master, origin/HEAD) [lguohan]
* c6aeedd 2020-06-25 | Updated NAT kernel patch for 4.19 buster (#147) [Akhilesh Samineni]
Signed-off-by: Guohan Lu <lguohan@gmail.com>
**- Why I did it**
Initially, the critical_processes file contains either the name of critical process or the name of group.
For example, the critical_processes file in the dhcp_relay container contains a single group name
`isc-dhcp-relay`. When testing the autorestart feature of each container, we need get all the critical
processes and test whether a container can be restarted correctly if one of its critical processes is
killed. However, it will be difficult to differentiate whether the names in the critical_processes file are
the critical processes or group names. At the same time, changing the syntax in this file will separate the individual process from the groups and also makes it clear to the user.
Right now the critical_processes file contains two different kind of entries. One is "program:xxx" which indicates a critical process. Another is "group:xxx" which indicates a group of critical processes
managed by supervisord using the name "xxx". At the same time, I also updated the logic to
parse the file critical_processes in supervisor-proc-event-listener script.
**- How to verify it**
We can first enable the autorestart feature of a specified container for example `dhcp_relay` by running the comman `sudo config container feature autorestart dhcp_relay enabled` on DUT. Then we can select a critical process from the command `docker top dhcp_relay` and use the command `sudo kill -SIGKILL <pid>` to kill that critical process. Final step is to check whether the container is restarted correctly or not.
The current stdout file which also includes the dut logs are very verbose and noisy.
We have manually installed it in the sonic-mgmt docker in our organization and tuned the pytest settings to produce very helpful and concise logs.
pytest-html plugins can be used to post-process the output in various ways based on our different and unique organizational needs.
Hence proposing to add this pkt to the docker file
**- Why I did it**
After discussed with Joe, we use the string "/usr/bin/syncd\s" in Monit configuration file to monitor
syncd process on Broadcom and Mellanox. Due to my careless, I did not find this bug during the
previous testing. If we use the string "/usr/bin/syncd" in Monit configuration file to monitor the
syncd process, Monit will not detect whether syncd process is running or not.
If we ran the command `sudo monit procmactch “/usr/bin/syncd”` on Broadcom, there will be three
processes in syncd container which matched this "/usr/bin/syncd": `/bin/bash /usr/bin/syncd.sh
wait`, `/usr/bin/dsserve /usr/bin/syncd –diag -u -p /etc/sai.d/sai.profile` and `/usr/bin/syncd –diag -
u -p /etc/sai.d/said.profile`. Monit will select the processes with the highest uptime (at there
`/bin/bash /usr/bin/syncd.sh wait`) to match and did not select `/usr/bin/syncd –diag -u -p
/etc/sai.d/said.profile` to match.
Similarly, On Mellanox Monit will also select the process with the highest uptime (at there
`/bin/bash /usr/bin/syncd.sh wait`) to match and did not select `/usr/bin/syncd –diag -u -p
/etc/sai.d/said.profile` to match.
That is why Monit is unable to detect whether syncd process is running or not if we use the string “/usr/bin/syncd” in Monit configuration file. If we use the string "/usr/bin/syncd\s" in Monit configuration file, Monit can filter out the process `/bin/bash /usr/bin/syncd.sh wait` and thus can correctly monitor the syncd process.
**- How I did it**
**- How to verify it**
Signed-off-by: Yong Zhao <yozhao@microsoft.com>
sonic-utils has sonic-yang-mgmt as build time deps, which inturn installs libyang.
libyang is needed to run newly added test.
If sonic-yang-mgmt is already built then libyang will not be installed in slave docker
without this PR and test will not run.
Signed-off-by: Praveen Chaudhary pchaudhary@linkedin.com
Add build flag TELEMETRY_WRITABLE. When set to "y" it will add a go build flag in the telemetry build that will enable telemetry write mode to allow configuration via gNMI Set RPC as well as operations via the gNOI RPC's. The default for TELEMETRY_WRITABLE is unset in which case telemetry is read-only. In read-only mode the Set RPC and all gNOI RPC's are disabled and will return an "Unsupported" error when called.
authored-by: Eric Seifert <eric@seifert.casa>
when portsyncd starts, it first enumerates all front panel ports
and marks them as old interfaces. Then, for new front panel ports
it checks if their indexes exist in previous sets. If yes, it will
treats them as old interfaces and ignore them.
The reason we have this check is because broadcom SAI only removes
front panel ports after sai switch init.
So, if portsyncd starts after orchagent, new interfaces could be
created before portsyncd and treated as old interface.
Signed-off-by: Guohan Lu <lguohan@gmail.com>
When building the SONiC image, used systemd to mask all services which are set to "disabled" in init_cfg.json.
This PR depends on https://github.com/Azure/sonic-utilities/pull/944, otherwise `config load_minigraph will fail when trying to restart disabled services.
* Change port index in port_config.ini to 1-based
* Add default port index to port_config.ini, change platform plugins to accept 1-based port index
* fix port index in sfp_event.py
To enable tagged vlan support by minigraph parser. This enables us to generate a config_db file that will enable SONiC device to operate using tagged and untagged vlan.
- Why I did it
New repo sonic-mgmt-common is introduced for the common translib related code. This commit adds build rules for this new repo.
- How I did it
Added sonic-mgmt-common submodule
Added build rules for the new sonic-mgmt-common repo. It creates two deb packages -- sonic-mgmt-common_1.0.0_{arch}.deb and sonic-mgmt-common-codegen_1.0.0_{arch}.deb. Package cache is enabled.
Added dependency on sonic-mgmt-common for mgmt-framework and telemetry debs and dockers.
- How to verify it
Full build and incremental builds
Basic ACL and interface opreations through REST, KLISH CLI and gNMI
- Description for the changelog
Git submodule and build rules for the new sonic-mgmt-common repo.
* Add secureboot support in boot0
* Initramfs changes for secureboot on Aboot devices
* Do not compress squashfs and gz in fs.zip
It doesn't make much sense to do so since these files are already
compressed.
Also not compressing the squashfs has the advantage of making it
mountable via a loop device.
* Add loopoffset parameter to initramfs-tools
FDB/ARP/Default routes files are deleted after swssconfig. This
makes debugging/validation of device conversion hard. This PR
saves those files in order to facilitate debugging of device conversion.
signed-off-by: Tamer Ahmed <tamer.ahmed@microsoft.com>
- Ensure all features (services) are in the configured state when hostcfgd starts
- Better functionalization of code
- Also replace calls to deprecated `has_key()` method in `tacacs_server_handler()` and `tacacs_global_handler()` with `in` keyword.
This PR depends on https://github.com/Azure/sonic-utilities/pull/944, otherwise `config load_minigraph` will fail when trying to restart disabled services.
While migrating to SONiC 20181130, identified a couple of issues:
1. union-mount needs /host/machine.conf parameters for vendor specific checks : however, in case of migration, the /host/machine.conf is extracted from ONIE only in https://github.com/Azure/sonic-buildimage/blob/master/files/image_config/platform/rc.local#L127.
2. Since grub.cfg is updated to have net.ifnames=0 biosdevname=0, 70-persistent-net.rules changes are no longer required.
To run the unit test for sonic-utilities/config/config_mgmt.py, we need sonic-yang-mgmt.
It is decided to not mock sonic-yang-mgmt because config_mgmt is highly dependent on sonic-yang-mgmt.
So It is good to catch any compatibility issues during build time rather than run time.
Signed-off-by: Praveen Chaudhary pchaudhary@linkedin.com
REST and telemetry servers were using "DEVICE_METADATA|x509" table for
server certificate configurations. This table has been deprecated now.
Enhanced REST server startup script to read server certificate file
path configurations from REST_SERVER table. Three more attributes -
server_crt, server_key and ca_crt are introduced as described in
https://github.com/Azure/SONiC/pull/550.
For backard compatibility, certificate configurations are read from
old "DEVICE_METADATA|x509" table if they (server_crt, server_key and
ca_crt) are not present in REST_SERVER table.
Fixes bug https://github.com/Azure/sonic-buildimage/issues/4291
Signed-off-by: Sachin Holla <sachin.holla@broadcom.com>
**- What I did**
Add support of **platform.json** parsing to **portconfig.py** file which is being used by **_sonic-cfggen_** and ***minigraph.py*** file under ***src/sonic-config-engine*** folder to get port config via get_port_config function.
**- How I did it**
1. **portconfig.py** file will first check whether the **platform.json** file is there or not. if not then whether port_config.ini file is there or not. Modified **get_port_config_file_name** for this purpose.
2. Added two separate functions i.e. **parse_platform_json_file** to get port attributes from **platform.json** and **gen_port_config** to generate port attributes.
3. Added another two functions i.e get_breakout_mode parse_breakout_mode to get breakout mode and parse breakout mode from platform.json respectively.
**- How to verify it**
rebuilt "sonic_config_engine-1.0" wheel package with all the test cases.All the below-mentioned test cases passed.
```
# Check whether all interfaces present or not as per platform.json
def test_platform_json_interfaces_keys(self):
# Check specific Interface with it's proper configuration as per platform.json
def test_platform_json_specific_ethernet_interfaces(self):
# Check all Interface with it's proper configuration as per platform.json
def test_platform_json_all_ethernet_interfaces(self):
```
Signed-off-by: Sangita Maity <sangitamaity0211@gmail.com>
**- Why I did it**
The tx_disable function isn't work for the accton_ax5835-54x device.
**- How I did it**
Fix the incorrect path of the sfp node path inside the util file.
**- How to verify it**
Test with
"sudo accton_as5835_54x_util.py show"
"sudo accton_as5835_54x_util.py set sfp"
There should see correct value for module_present and module_tx_disable. And should able to set it.
Signed-off-by: kuanyu_chen <kuanyu_chen@edge-core.com>
Don't limit iptables connection tracking to TCP protocol; allow connection tracking for all protocols. This allows services like NTP, which is UDP-based, to receive replies from an NTP server even if the port is blocked, as long as it is in reply to a request sent from the device itself.
* Fix the Build on 201911 (Stretch) where the directory
/usr/lib/systemd/system/ does not exist so creating
manually. Change should not harm Master (buster) where
the directory is created by Linux
* Fix as per review comments
