binding:profile update always trigger port rebind
Bug #1632658 reported by
Na Zhu
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Incomplete
|
Undecided
|
srikanth |
Bug Description
Currently, binding:profile update always trigger port rebind, the rebind behavior brings problems if the MD handler the port status for some special purpose, I think it is more reasonable to ask MD whether need rebind.
From the last section of binding:profile bp (https:/
Changed in neutron: | |
assignee: | nobody → raju (raju-kulal) |
Changed in neutron: | |
assignee: | raju (raju-kulal) → srikanth (k1039485) |
To post a comment you must log in.
Hi Na Zhu,
As per the detail analysis from the mentioned Blueprint as well as neutron-specs there are no specific handling wherein registered mechanism drivers will be notified to validate the original(i.e. updated attribute) binding:profile attribute to see if there is any requirement for re-binding to take place with the respective ML2 Plugin to validate with the reference Current PortContext binding:profile attributes.
So in short there is no handling in code where unnecessary rebinding can be taken care with prior validation or notification from the respective Mechanism drivers. Correct my understanding on the same.
To understand every aspect of the port update, i have tested every possible use case combination with the binding:profile - same, different and Invalid values.
And as part of the code analysis, it is pretty clear that rebinding with the new binding:profile attribute will be happening (except for the Invalid message string) every time irrespective of DuplicateEntries in DB.
So as per our understanding following methods will ideally take care of the attributes for every update happening w.r.t the dictionary:
1. update_port port_precommit port_postcommit
2. process_update_port
3. update_
4. update_
5. commit_port_binding
As part of the above methods in place which are currently taking care of port update we have the possibility to see if there is some new Proposed changes which will send Notification during the DB transactions commit process to the respective Mechanism drivers to validate the need for re-binding for the required ML2 plugins. If so then your requirement can be fulfilled.
We have already sent a mail across to Robert Kukura to understand on his future proposals(if any).
if there are any further discussions happening will keep things posted.
Let us know if we can move this Bug to Wishlist for Future reference instead of affected Bugs.
******** Tests which was triaged to check the behavior of the code************** ------- ------- ------- +------ ------- ------- ------- ------- ----+ ------- ------- ------- +------ ------- ------- ------- ------- ----+ zone_hints | | dc64-495c- 8da1-2a49a29a4e 05 | enabled | True | network_ type | vxlan | physical_ network | | segmentation_ id | 1022 ...
$ neutron net-create test
Created a new network:
+------
| Field | Value |
+------
| admin_state_up | True |
| availability_
| availability_zones | |
| created_at | 2017-02-15T09:12:13 |
| description | |
| id | dec7e34d-
| ipv4_address_scope | |
| ipv6_address_scope | |
| mtu | 1450 |
| name | test |
| port_security_
| provider:
| provider:
| provider: