[DPB] Different configuration section for interface with applied and unapplied breakout and same split mode

[Hedgehog-Guru]

Description
Configuration for an interface after the applying breakout has a different format in the config_db.json file.

Steps to reproduce the issue

1. Show configuration of the interface in config_db.json before breakout:

more /etc/sonic/config_db.json
... output omitted...

        "Ethernet36": {
            "brkout_mode": "1x100G[50G,40G,25G,10G]"
        },
        "Ethernet104": {
            "brkout_mode": "1x100G[50G,40G,25G,10G]
        },
        "Ethernet12": {
            "brkout_mode": "1x100G[50G,40G,25G,10G]"
        }

... output omitted...

2. Breakout interface:

config interface breakout Etherne96 2x50G

3. Unbreakout interface to 1x100G mode:

config interface breakout Ethernet96 1x100G

4. Save configuration

config save -y

5. Check config_db.json

Describe the results you received
Configuration for the same interface with the same breakout mode are differents after the breakout/unbreakout apply.

        "Ethernet36": {
            "brkout_mode": "1x100G[50G,40G,25G,10G]"
        },
        "Ethernet104": {
            "brkout_mode": "1x100G"
        },
        "Ethernet12": {
            "brkout_mode": "1x100G[50G,40G,25G,10G]"
        }

Describe the results you expected

The configuration string for the same breakout mode in the config_db.json file must be the same before and after applying the breakout mode to the interface.

Output of show version

SONiC Software Version: SONiC.dpb_qa_image_01_02_2021.0-904ec5a17
Distribution: Debian 10.7
Kernel: 4.19.0-9-2-amd64
Build commit: 904ec5a17
Build date: Mon Feb  1 19:55:57 UTC 2021
Built by: vadymh@r-build-sonic03

Platform: x86_64-mlnx_msn2700-r0
HwSKU: Mellanox-SN2700
ASIC: mellanox
ASIC Count: 1
Serial Number: MT1550X12437
Uptime: 15:15:44 up 26 min,  2 users,  load average: 4.44, 5.34, 4.34

Docker images:
REPOSITORY                    TAG                                   IMAGE ID            SIZE
docker-syncd-mlnx             dpb_qa_image_01_02_2021.0-904ec5a17   0be29560ed94        539MB
docker-syncd-mlnx             latest                                0be29560ed94        539MB
docker-sflow                  dpb_qa_image_01_02_2021.0-904ec5a17   bb35e3500d6c        405MB
docker-sflow                  latest                                bb35e3500d6c        405MB
docker-snmp                   dpb_qa_image_01_02_2021.0-904ec5a17   a0382194454f        435MB
docker-snmp                   latest                                a0382194454f        435MB
docker-dhcp-relay             dpb_qa_image_01_02_2021.0-904ec5a17   9fbff561871b        401MB
docker-dhcp-relay             latest                                9fbff561871b        401MB
docker-teamd                  dpb_qa_image_01_02_2021.0-904ec5a17   57194fe91511        404MB
docker-teamd                  latest                                57194fe91511        404MB
docker-nat                    dpb_qa_image_01_02_2021.0-904ec5a17   83b8bbc09610        407MB
docker-nat                    latest                                83b8bbc09610        407MB
docker-router-advertiser      dpb_qa_image_01_02_2021.0-904ec5a17   6e4213d19ae2        394MB
docker-router-advertiser      latest                                6e4213d19ae2        394MB
docker-platform-monitor       dpb_qa_image_01_02_2021.0-904ec5a17   2f3634c6050c        684MB
docker-platform-monitor       latest                                2f3634c6050c        684MB
docker-lldp                   dpb_qa_image_01_02_2021.0-904ec5a17   835b3f7e2b2a        434MB
docker-lldp                   latest                                835b3f7e2b2a        434MB
docker-database               dpb_qa_image_01_02_2021.0-904ec5a17   db5bfb2a9fe7        394MB
docker-database               latest                                db5bfb2a9fe7        394MB
docker-sonic-mgmt-framework   dpb_qa_image_01_02_2021.0-904ec5a17   8b93727ceace        612MB
docker-sonic-mgmt-framework   latest                                8b93727ceace        612MB
docker-orchagent              dpb_qa_image_01_02_2021.0-904ec5a17   9ea288be1cde        423MB
docker-orchagent              latest                                9ea288be1cde        423MB
docker-macsec                 dpb_qa_image_01_02_2021.0-904ec5a17   9ba4cccc5979        408MB
docker-macsec                 latest                                9ba4cccc5979        408MB
docker-sonic-telemetry        dpb_qa_image_01_02_2021.0-904ec5a17   ce3dfd9de85b        469MB
docker-sonic-telemetry        latest                                ce3dfd9de85b        469MB
docker-fpm-frr                dpb_qa_image_01_02_2021.0-904ec5a17   3a79df1df250        422MB
docker-fpm-frr                latest                                3a79df1df250        422MB

sonic_dump_r-qa-sw-eth-53_20210202_151530.tar.gz

[zhenggen-xu]

It seems you have two modes defined in platform.json: "1x100G[50G,40G,25G,10G]" and "1x100G", and if you set to 1x100G, it will be saved as 1x100G. So this is expected. Closing it. Feel free to re-open if needed.

[Hedgehog-Guru]

Hi,
In attachment platform.json file. This file does not contain two different modes - with and without section in square brackets.
Arguments to reopen this issue:

1. Configuration parsing system should correctly input the right parameters to configuration files if CLI with different input options allowed. For example, if the command has a short and long version of the CLI command - the written line in the config file should be the same.
2. With 1x100G line in the configuration file I faced another issue - [DPB] After a few consecutive breakout\unbreakout of the interface, the feature stop working #6610.
3. If different configuration lines available in the configuration file it is hard to parse this file with another tool;
4. It is a bad user experience to have different configuration lines in the file that have the same meaning and this practice has never been seen in other industry-leading projects.

So it looks like the problem is much deeper than just two lines in platform.json file. And I want to ask you to reopen this issue and help with a fix.

platform.json.gz

[Hedgehog-Guru]

@zhenggen-xu could you please take a look

[Hedgehog-Guru]

@anshuv-mfst , I was not able to re-open the bug.
Please extend rights for my account in order to have the ability to reopen at least my bugs :-)
Thanks.

[zhenggen-xu]

Hi,
In attachment platform.json file. This file does not contain two different modes - with and without section in square brackets.
Arguments to reopen this issue:

1. Configuration parsing system should correctly input the right parameters to configuration files if CLI with different input options allowed. For example, if the command has a short and long version of the CLI command - the written line in the config file should be the same.
2. With 1x100G line in the configuration file I faced another issue - [DPB] After a few consecutive breakout\unbreakout of the interface, the feature stop working #6610.
3. If different configuration lines available in the configuration file it is hard to parse this file with another tool;
4. It is a bad user experience to have different configuration lines in the file that have the same meaning and this practice has never been seen in other industry-leading projects.

So it looks like the problem is much deeper than just two lines in platform.json file. And I want to ask you to reopen this issue and help with a fix.

platform.json.gz

Understood the need of the fix if that was what happened. If you only have 1x100G[50G,40G,25G,10G], the below CLI command should fail:
config interface breakout Ethernet96 1x100G

Can you confirm if that succeed with the platform.json you attached? If so, @samaity can take a look.

[Hedgehog-Guru]

Command succeed with the attached platform.json:

config interface breakout Ethernet96 1x100G

[zhenggen-xu]

@samaity Please take a look, it seems to be a simple matching issue in CLI where we should match the whole string instead.