- Why I did it
Change YANG model to support syslog rate limit configuration feature
- How I did it
modified sonic-syslog.yang and sonic-feature.yang to support the new added configuration schema
- How to verify it
Unit test
Added Support to runtime render bgp and teamd feature `state` and lldp `has_asic_scope` flag
Needed for SONiC on chassis.
Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>
Co-authored-by: mlok <marty.lok@nokia.com>
- Why I did it
The values for config_db "docker_routing_config_mode" are:
separated: FRR config generated from ConfigDB, each FRR daemon has its own config file
unified: FRR config generated from ConfigDB, single FRR config file
split: FRR config not generated from ConfigDB, each FRR daemon has its own config file
This commit adds:
split-unified: FRR config not generated from ConfigDB, single FRR config file
- How I did it
In docker_init.sh, when split-unified is used, the FRR configs are not generated
from ConfigDB. What's more, "service integrated-vtysh-config" is configured in vtysh.conf.
- How to verify it
FRR config not overwritten when FRR container starts.
Signed-off-by: Arnaud le Taillanter <a.letaillanter@criteo.com>
Changes:
-- Change name-space from Azure to sonic-net.
-- Sort yang list in setup.py for yang-models list.
#### Why I did it
Sonic repo has moved to Linux-foundation.
#### How I did it
[yang-models]: Change name-space from Azure to sonic-net.
#### How to verify it
PR Tests are good enough to verify.
- Why I did it
Add the ability to the user to save the loglevel and make it persistent to reboot.
- How I did it
Move the logger tables from the LOGLEVEL DB to the CONFIG DB. Add new yang model to verify the new config schema.
- How to verify it
1. change the orchagent loglevel (for example) -> swssloglevel -c orchagent -l DEBUG
2. save the loglevel -> run config save
3. reboot
4. verify that the orchagent log level is still DEBUG ->run run redis-cli -n 4 hgetall "LOGGER|orchagent"
What I did
Filter port invalid MTU configuration
How I did it
Adjust the MTU value to the range of [68,9216]
How to verify it
Use "config interface mtu Ethernet1 40" command to configure the port MTU. The following error will occur in SWSS.
changes:
-- yang model for dhcp_server table.
-- tests.
Why I did it
yang model for dhcp_server table.
How I did it
-- yang model for dhcp_server table.
-- yang model tests.
How to verify it
-- yang model build time tests.
changes:
-- yang model for mpls_tc_to_tc_map table.
-- tests.
#### Why I did it
yang model for mpls_tc_to_tc_map table.
#### How I did it
-- yang model for mpls_tc_to_tc_map table.
-- yang model tests.
#### How to verify it
-- yang model build time tests.
This is causing a build failure for all builds. The PR build was incorrectly marked as passing due to a different build issue.
libyang[0]: Regular expression "(/[a-zA-Z0-9_-.]+)*/([a-zA-Z0-9_-.]+)./[a-z]{3}" is not valid (".]+)*/([a-zA-Z0-9_-.]+)./[a-z]{3})$": range out of order in character class).
libyang[0]: Module "sonic-restapi" parsing failed.
ERROR:YANG-TEST: Exception >Module "sonic-restapi" parsing failed.< in /sonic/src/sonic-yang-models/tests/yang_model_tests/test_yang_model.py:114
ERROR:YANG-TEST: Exception >Module "sonic-restapi" parsing failed.< in /sonic/src/sonic-yang-models/tests/yang_model_test
This reverts commit e1765121b2.
Why I did it
Address issue #10970
sign-off: Jing Zhang zhangjing@microsoft.com
How I did it
Add sonic-mux-cable.yang and unit tests.
How to verify it
Compile Compile target/python-wheels/sonic_yang_mgmt-1.0-py3-none-any.whl and target/python-wheels/sonic_yang_models-1.0-py3-none-any.whl.
Pass sonic-config-engine unit test.
Which release branch to backport (provide reason below if selected)
201811
201911
202006
202012
202106
202111
202205
Description for the changelog
Link to config_db schema for YANG module changes
f8fe41a023/src/sonic-yang-models/doc/Configuration.md (mux_cable)
Why I did it
Address issue #10966
sign-off: Jing Zhang zhangjing@microsoft.com
How I did it
Add sonic-peer-switch.yang and unit tests.
How to verify it
Compile Compile target/python-wheels/sonic_yang_mgmt-1.0-py3-none-any.whl and target/python-wheels/sonic_yang_models-1.0-py3-none-any.whl.
Which release branch to backport (provide reason below if selected)
201811
201911
202006
202012
202106
202111
202205
Description for the changelog
Link to config_db schema for YANG module changes
b721ff87b9/src/sonic-yang-models/doc/Configuration.md (peer-switch)
Fix#10549Fix#10550
#### Why I did it
Create sonic yang model for SNMP
Tables:SNMP, SNMP_COMMUNITY
#### How I did it
Defined yang models based for SNMP based on snmp.yml
#### How to verify it
Added test cases to verify
Why I did it
This PR is to update Yang model for pfc_enable and pfcwd_sw_enable fields to support more than 2 queues, like 2,3,4,6.
Before this change, the regex "[0-7](,[0-7])?" accepts only no more than 2 queues.
How I did it
Update the regex pattern for pfc_enable and pfcwd_sw_enable, from "[0-7](,[0-7])?" to "[0-7](,[0-7])*
How to verify it
The change is verified by UT. The test input is updated to cover the change.
collected 3 items
tests/test_sonic_yang_models.py .. [ 66%]
tests/yang_model_tests/test_yang_model.py .
#### Why I did it
To support Yang models for SRV6 CM
#### How I did it
Added yang models for SRV6 MY_SID_ENTRY and Nexthop
#### How to verify it
Added SRV6 CRM yang tests.
#### Which release branch to backport (provide reason below if selected)
202111
- Why I did it
To implement Syslog Source IP feature
- How I did it
Added the relevant yang doc
- How to verify it
N/A
Signed-off-by: Nazarii Hnydyn <nazariig@nvidia.com>
Why I did it
SONiC Yang support for VXLAN
How I did it
Added a new sonic-vxlan.yang file.
Please refer to EVPN VXLAN HLD for DB details
https://github.com/Azure/SONiC/tree/master/doc/vxlan/EVPN
How to verify it
Added tests for sonic vxlan yang.
#### Why I did it
To address https://github.com/Azure/sonic-buildimage/issues/11110 - Add yang model unit test for check_up_status field type
#### How I did it
Add check_up_status with different values in sample_config_db.json and
the field with correct and incorrect values in feature.json
#### How to verify it
Build sonic_yang_models-1.0-py3-none-any.whl
- Why I did it
To implement Syslog Source IP feature based on HLD: https://github.com/sonic-net/SONiC/pull/1002
- How I did it
Added the relevant yang model
- How to verify it
Added unit test
Signed-off-by: Nazarii Hnydyn <nazariig@nvidia.com>
#### Why I did it
Support the following tables which were introduced during dynamic buffer calculation
- LOSSLESS_TRAFFIC_PATTERN
- DEFAULT_LOSSLESS_BUFFER_PARAMETER
#### How I did it
- LOSSLESS_TRAFFIC_PATTERN
|name|type|range|mandatory|description|
|---|---|---|---|---|
|mtu|uint16|64~10240|true|The maximum packet size of a lossless packet|
|small_packet_percentage|uint8|0~100|true|The percentage of small packet|
- DEFAULT_LOSSLESS_BUFFER_PARAMETER
|name|type|range|mandatory|description|
|---|---|---|---|---|
|default_dynamic_th|int8|-8~7|true|The default dynamic_th for all buffer profiles that are dynamically generated for lossless PG|
|over_subscribe_ratio|uint16|-|false|The oversubscribe ratio for shared headroom pool.|
|||||Semantically, the upper bound is the number of physical ports but it can not be represented in the yang module. So we keep the upper bound open. As the type is (signed) integer whose lower bound is 0 by nature, we do not need to specify the range.|
#### How to verify it
Run unit test
- Why I did it
An issue is encountered when a value "False" is written for a feature in "check_up_status" field, which does not pass YANG validation.
- How I did it
We usually use stypes::boolean_type for such fields, even in this YANG model. This custom type, supports "False" value.
- How to verify it
Write "False" in "check_up_status" field and see if YANG validation passes.
Signed-off-by: Stepan Blyschak <stepanb@nvidia.com>
* [BGP]Adding configuration knob to allow advertise Loopback ipv6 /128 prefix
By default when IPv6 address is configured with /128 as subnet mask in Loopback0 interface, it will be advertised as prefix with /64 subnet.
To control this behavior a new field 'bgp_adv_lo_prefix_as_128' is introduced in DEVICE_METADATA table which when set to true will advertise prefix with /128 subnet as it is.
- Why I did it
Yang Model about password hardening feature, the sonic CLI of this feature was autogenerated from this Yang model
- How I did it
Create new Yang model in src/sonic-yang-models/yang-models/sonic-passwh.yang.
- How to verify it
There are unitests(yang test) in this P.R covering all the passwords policies with good and bad values cases.
Or is possible manually using the config/show password commands that were autogenerated from this Yang model. (this CLI code added in sonic-utilities)
#### Why I did it
For yang model, sample_config_db.json file was missing Sample data for the features SNAT/DNAT/IPMC
#### How I did it
Added the SNAT,DNAT,IPMC(low Threshold/high threshold/threshold_type)entries in CRM table.
#### How to verify it
With sanity Build/test only.
- Why I did it
With SAI V.1.10.2, new interface types CR8/SR8/KR8/LR8 have been introduced, we should also support them from the CLI configuration.
- How I did it
Add new enum for the new interface types
- How to verify it
Run the "config interface type" command to verify new interface types can be accepted and handled correctly.
Signed-off-by: Kebo Liu <kebol@nvidia.com>
- Why I did it
YANG schema is missing for sonic-telemetry
- How I did it
Added YANG schema to sonic-yang-models and appropriate unit tests inside of test and test_config
- How to verify it
Build sonic-yang-models python wheels target and verify that unit tests are passing
Why I did it
At present, there is no mechanism in an event driven model to know that the system is up with all the essential sonic services and also, all the docker apps are ready along with port ready status to start the network traffic. With the asynchronous architecture of SONiC, we will not be able to verify if the config has been applied all the way down to the HW. But we can get the closest up status of each app and arrive at the system readiness.
How I did it
A new python based system monitor tool is introduced under system-health framework to monitor all the essential system host services including docker wrapper services on an event based model and declare the system is ready. This framework gives provision for docker apps to notify its closest up status. CLIs are provided to fetch the current system status and also service running status and its app ready status along with failure reason if any.
How to verify it
"show system-health sysready-status" click CLI
Syslogs for system ready
This is part of HLD Azure/SONiC#925
#### Why I did it
Add link-training support
#### How I did it
Update SONiC YANG for port link-training support
#### Description for the changelog
Add "link_training" to sonic-port.yang
#### Link to config_db schema for YANG module changes
https://github.com/sonic-net/SONiC/wiki/Configuration#port
Why I did it
Fixes#10793
How I did it
Removed the switch_type validation from the Yang model.
How to verify it
compile sonic_yang_mgmt-1.0-py3-none-any.whl and sonic_yang_mgmt-1.0-py3-none-any.whl
Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <arlakshm@microsoft.com>
