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 ?
…et#21095) Adding the below fix from FRR FRRouting/frr#17297 This is to fix the following crash which is a statistical issue [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/lib/frr/zebra -A 127.0.0.1 -s 90000000 -M dplane_fpm_nl -M snmp'. Program terminated with signal SIGABRT, Aborted. #0 0x00007fccd7351e2c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 [Current thread is 1 (Thread 0x7fccd6faf7c0 (LWP 36))] (gdb) bt #0 0x00007fccd7351e2c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007fccd7302fb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007fccd72ed472 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007fccd75bb3a9 in _zlog_assert_failed (xref=xref@entry=0x7fccd7652380 <_xref.16>, extra=extra@entry=0x0) at ../lib/zlog.c:678 #4 0x00007fccd759b2fe in route_node_delete (node=<optimized out>) at ../lib/table.c:352 #5 0x00007fccd759b445 in route_unlock_node (node=0x0) at ../lib/table.h:258 #6 route_next (node=<optimized out>) at ../lib/table.c:436 #7 route_next (node=node@entry=0x56029d89e560) at ../lib/table.c:410 #8 0x000056029b6b6b7a in if_lookup_by_name_per_ns (ns=ns@entry=0x56029d873d90, ifname=ifname@entry=0x7fccc0029340 "PortChannel1020") at ../zebra/interface.c:312 #9 0x000056029b6b8b36 in zebra_if_dplane_ifp_handling (ctx=0x7fccc0029310) at ../zebra/interface.c:1867 #10 zebra_if_dplane_result (ctx=0x7fccc0029310) at ../zebra/interface.c:2221 #11 0x000056029b7137a9 in rib_process_dplane_results (thread=<optimized out>) at ../zebra/zebra_rib.c:4810 #12 0x00007fccd75a0e0d in thread_call (thread=thread@entry=0x7ffe8e553cc0) at ../lib/thread.c:1990 sonic-net#13 0x00007fccd7559368 in frr_run (master=0x56029d65a040) at ../lib/libfrr.c:1198 sonic-net#14 0x000056029b6ac317 in main (argc=9, argv=0x7ffe8e5540d8) at ../zebra/main.c:478
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)