Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[GCU] Update path to xpath conversion logic to most recent sonic YANG updates Supporting `Type_1_list_maps_model #2034

Closed
ghooo opened this issue Jan 24, 2022 · 0 comments · Fixed by #2171
Closed

[GCU] Update path to xpath conversion logic to most recent sonic YANG updates Supporting `Type_1_list_maps_model #2034

ghooo opened this issue Jan 24, 2022 · 0 comments · Fixed by #2171
Assignees
@ghooo
Labels
generic-config-updater

Comments

@ghooo
Copy link
Contributor

ghooo commented Jan 24, 2022 •
edited
Loading

Description

sonic_yang_mgmt follows these guidelines in order to convert from config_db to config_yang and vice versa.
in GCU we rely on the same guidelines to convert from config_db path to config_yang xpath and vice versa.

There were modifications to how sonic_yang_mgmt converts data recently, and these changes are not supported by gcu, the changes are the following:

Please make sure to add tests for CABLE_LENGTH and other tables that are affected by this change.

Steps to reproduce the issue

Describe the results you received

Describe the results you expected

Additional information you deem important (e.g. issue happens only occasionally)

Output of show version

(paste your output here)
@ghooo ghooo mentioned this issue Jan 24, 2022
Closed
@ghooo ghooo mentioned this issue Jan 26, 2022
Closed
@ghooo ghooo changed the title [GCU] Update path to xpath conversion logic to most recent sonic YANG updates [GCU] Update path to xpath conversion logic to most recent sonic YANG updates Supporting `Type_1_list_maps_model Feb 3, 2022
ghooo added a commit to ghooo/sonic-utilities that referenced this issue Feb 17, 2022
@ghooo
ignoring ADD_RACK test for now until fixing issue sonic-net#2034
0581219
stepanblyschak pushed a commit to stepanblyschak/sonic-utilities that referenced this issue Apr 18, 2022
@theasianpianist
[swss]: Submodule update: (#10311)
f4233d7 
Include following commits:
    - d061e27 [tunnelmgrd]: Warm boot support (sonic-net#2166)
    - 73ced6e Remove port serdes object before removing port (sonic-net#2152)
    - 6ac0b9b [CoPP] Add always_enabled field to coppmgr logic (sonic-net#2034) (sonic-net#2147)

Signed-off-by: Lawrence Lee <lawlee@microsoft.com>
@qiluo-msft qiluo-msft mentioned this issue Apr 28, 2022
Merged
@ghooo ghooo mentioned this issue May 18, 2022
Merged
ghooo added a commit that referenced this issue May 25, 2022
@ghooo
[GCU] Handling type1 lists (#2171)
f5af780 
#### What I did
Fixes #2034

Which lists where handled before in ConfigDb to YANG conversion?
- Dictionary of key to Object e.g.
```
"TACPLUS_SERVER": {
    "1.1.1.1": {            <= Key: Object (i.e. {...})
        "priority": "1", 
        "tcp_port": "49"
    }, 
    "1.1.1.2": {
        "priority": "1", 
        "tcp_port": "49"
    },
    "1.1.1.3": {
        "priority": "1", 
        "tcp_port": "49"
    } 
}
```
- List of values
```
"VLAN": {
    "Vlan1000": {
        "vlanid": "1000",
        "dhcp_servers": [    <= Values
            "192.0.0.1",
            "192.0.0.2",
            "192.0.0.3",
            "192.0.0.4"
        ]
    }
}
```
- But there is no handling of Dictionary of Key to Value
```
"DOT1P_TO_TC_MAP": {
    "Dot1p_to_tc_map1": {    <= Key: Value
            "1": "1",
            "2": "2",
            "3": "1",
            "4": "2"
        }
    },
```

Refer to sonic-net/sonic-buildimage#7375 for more info about how Type 1 list ConfigDb is getting converted to SonicYang.

After checking how type1 is handled during ConfigDb to SonicYang conversion. Check the unit-tests here for converting ConfigDb Path to SonicYang xpath.


Also added CABLE_LENGTH to ADD_RACK and REMOVE_RACK tests.

#### How I did it

When handling a list, check if it is of type1. If that's the case call type1 list handling.

#### How to verify it
unit-test

#### Previous command output (if the output of a command-line utility has changed)

#### New command output (if the output of a command-line utility has changed)
yxieca pushed a commit that referenced this issue Jun 17, 2022
@ghooo @yxieca
[GCU] Handling type1 lists (#2171)
5443b3c 
#### What I did
Fixes #2034

Which lists where handled before in ConfigDb to YANG conversion?
- Dictionary of key to Object e.g.
```
"TACPLUS_SERVER": {
    "1.1.1.1": {            <= Key: Object (i.e. {...})
        "priority": "1", 
        "tcp_port": "49"
    }, 
    "1.1.1.2": {
        "priority": "1", 
        "tcp_port": "49"
    },
    "1.1.1.3": {
        "priority": "1", 
        "tcp_port": "49"
    } 
}
```
- List of values
```
"VLAN": {
    "Vlan1000": {
        "vlanid": "1000",
        "dhcp_servers": [    <= Values
            "192.0.0.1",
            "192.0.0.2",
            "192.0.0.3",
            "192.0.0.4"
        ]
    }
}
```
- But there is no handling of Dictionary of Key to Value
```
"DOT1P_TO_TC_MAP": {
    "Dot1p_to_tc_map1": {    <= Key: Value
            "1": "1",
            "2": "2",
            "3": "1",
            "4": "2"
        }
    },
```

Refer to sonic-net/sonic-buildimage#7375 for more info about how Type 1 list ConfigDb is getting converted to SonicYang.

After checking how type1 is handled during ConfigDb to SonicYang conversion. Check the unit-tests here for converting ConfigDb Path to SonicYang xpath.


Also added CABLE_LENGTH to ADD_RACK and REMOVE_RACK tests.

#### How I did it

When handling a list, check if it is of type1. If that's the case call type1 list handling.

#### How to verify it
unit-test

#### Previous command output (if the output of a command-line utility has changed)

#### New command output (if the output of a command-line utility has changed)
@isabelmsft isabelmsft mentioned this issue Jun 22, 2022
Open
5 tasks
yxieca pushed a commit that referenced this issue Jun 23, 2022
@ghooo @yxieca
[GCU] Handling type1 lists (#2171)
785508d 
#### What I did
Fixes #2034

Which lists where handled before in ConfigDb to YANG conversion?
- Dictionary of key to Object e.g.
```
"TACPLUS_SERVER": {
    "1.1.1.1": {            <= Key: Object (i.e. {...})
        "priority": "1", 
        "tcp_port": "49"
    }, 
    "1.1.1.2": {
        "priority": "1", 
        "tcp_port": "49"
    },
    "1.1.1.3": {
        "priority": "1", 
        "tcp_port": "49"
    } 
}
```
- List of values
```
"VLAN": {
    "Vlan1000": {
        "vlanid": "1000",
        "dhcp_servers": [    <= Values
            "192.0.0.1",
            "192.0.0.2",
            "192.0.0.3",
            "192.0.0.4"
        ]
    }
}
```
- But there is no handling of Dictionary of Key to Value
```
"DOT1P_TO_TC_MAP": {
    "Dot1p_to_tc_map1": {    <= Key: Value
            "1": "1",
            "2": "2",
            "3": "1",
            "4": "2"
        }
    },
```

Refer to sonic-net/sonic-buildimage#7375 for more info about how Type 1 list ConfigDb is getting converted to SonicYang.

After checking how type1 is handled during ConfigDb to SonicYang conversion. Check the unit-tests here for converting ConfigDb Path to SonicYang xpath.


Also added CABLE_LENGTH to ADD_RACK and REMOVE_RACK tests.

#### How I did it

When handling a list, check if it is of type1. If that's the case call type1 list handling.

#### How to verify it
unit-test

#### Previous command output (if the output of a command-line utility has changed)

#### New command output (if the output of a command-line utility has changed)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ghooo ghooo

Labels
generic-config-updater
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[GCU] Handling type1 lists ghooo/sonic-utilities
1 participant
@ghooo