merge OTSS and Syncd-OT to the OTN repository #9
Conversation
redirect submodules to sonic-otn repositories add otn vs platform, virtual-ot device, otss service and otairedis repository add otairedis and otss submodule update otairedis and swss-common submodule add docker-orchagent-ot in the bullseye dockers add otss_vars.j2 in otss docker image delete board mode in virtual transponder default configuration update sonic-swss-common submodule
sonic-otn temporary pipeline configuration [action]enable build jobs for sonic-otn
There was a problem hiding this comment.
One observation here is the duplicate definition of attributes across different line cards. I do understand that there are differences across different line cards but at the same time there are more commonalities as well (E.g. FlexCounter). In general, does it make sense to think about line common as a container to capture all functional commonalities across line cards from different vendors ?
There was a problem hiding this comment.
@skayamku This flexcounter.json is used to configure the flexcounter in the syncd container (https://github.com/sonic-otn/SONiC-OTN/blob/main/documentation/otn_otss_hld.md#234-flexcounter-configuration). There are different sampling statistics (gauge, counter and status) for different OTN linecard. Vendors can define the specific statistics parameters for various hardware (OLP, OTDR, OCM, etc). There are small amount of common statistics among these OTN cards, for example, the statistics of OTN linecards ( CPU usage, memory usage, temperature, etc.). Vendor can create common flexcounter configure file (j2 file) and include these common file in the target linecard flexcounter.j2.
| "BGP_DEVICE_GLOBAL": { | ||
| "STATE": { | ||
| "tsa_enabled": "false" | ||
| } | ||
| }, | ||
| {%- set features = [("bgp", "{% if not DEVICE_RUNTIME_METADATA['ETHERNET_PORTS_PRESENT'] or ('CHASSIS_METADATA' in DEVICE_RUNTIME_METADATA and DEVICE_RUNTIME_METADATA['CHASSIS_METADATA']['module_type'] in ['supervisor']) %}disabled{% else %}enabled{% endif %}", false, "enabled"), |
There was a problem hiding this comment.
Are there any plans to bring in an IGP routing protocol for routing of management traffic via in-band channel (OSC) ? If yes, does it make sense to retain FRR in optical package ?
There was a problem hiding this comment.
@skayamku The BGP container in SONiC had two implementations, FRR and GOBGP. FRR is the default routing stack, and it supports the IGP, for example, OSPF over OSC channel.
In init_cfg.json, we need to enable one BGP instance in the OTN product.
There was a problem hiding this comment.
As per the changes here, we are planning to run all service scrips that are part of baseline switch. This may require further review considering that optical devices may not require all services.
| @@ -137,7 +137,7 @@ INCLUDE_SYSTEM_TELEMETRY = n | |||
| INCLUDE_ICCPD = n | |||
|
|
|||
| # INCLUDE_SFLOW - build docker-sflow for sFlow support | |||
| INCLUDE_SFLOW = y | |||
| INCLUDE_SFLOW = n | |||
|
|
|||
| # INCLUDE_MGMT_FRAMEWORK - build docker-sonic-mgmt-framework for CLI and REST server support | |||
| INCLUDE_MGMT_FRAMEWORK = y | |||
There was a problem hiding this comment.
As per my understanding, management framework is not matured enough for wide adoption. The use case in switching world is limited right now. Are we planning to bring in unified manageability for optical devices via this daemon ?
Why I did it
Work item tracking
How I did it
How to verify it
Which release branch to backport (provide reason below if selected)
Tested branch (Please provide the tested image version)
Description for the changelog
Link to config_db schema for YANG module changes
A picture of a cute animal (not mandatory but encouraged)