[NETVIRT-338] No handler for the "admin_state_up" attribute Created: 08/Dec/16 Updated: 19/Oct/17 Resolved: 10/Dec/16 |
|
| Status: | Resolved |
| Project: | netvirt |
| Component/s: | General |
| Affects Version/s: | Carbon |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Johnson Li | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||
| External issue ID: | 7325 | ||||||||
| Description |
|
When I ran the Openstack tempest scenario test, I got failure for the case This case boots a VM server and then tries to ping the VM instance outside to the VM with floating IP, and then sets port's attribute "admin_state_up" to False, and then check the connectivity again, the expected result is that the VM should be unreachable, but the actual test result is the VM could still be reachable. I roughly checked codes of OpenDaylight Netvirt project, there are some codes to handle the openstack command to change the "admin_state_up" attribute from True to False and then store the value to MD-SAL I also noticed that there is no codes to set the Interface's admin_state column in the OVSDB table, due to there is no such attributes for the termination endpoint. Even through I used the command " sudo ovsdb-client -v transact '["Open_vSwitch", {"op" : "update", "table" : "Interface", "where": [["_uuid", "==", ["uuid", "b1d9c977-3ec7-48cc-8072-ae8d888b7ef8"]]], "row":{"admin_state": "down"}}]' " to set the admin_state to down for the port, the OVS still forwards packet for that port [This might be a bug for the OVS, too. But I still think that once we set up "admin_state_up" to False, we should set the "admin_state" to down for the interface related to the neutron port.] |
| Comments |
| Comment by Koby Aizer [ 10/Dec/16 ] |
|
I believe this issue is already documented in Closing this one as duplicate to keep a single thread on this issue. Thanks |