binding:profile update always trigger port rebind

Bug #1632658 reported by Na Zhu
This bug affects 1 person
Affects Status Importance Assigned to Milestone

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 (, it also mentioned that should not rebind if MD do not need.

raju (raju-kulal)
Changed in neutron:
assignee: nobody → raju (raju-kulal)
srikanth (k1039485)
Changed in neutron:
assignee: raju (raju-kulal) → srikanth (k1039485)
Revision history for this message
Poonam Ghosh (poonam-ghosh) wrote :
Download full text (9.0 KiB)

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
2. process_update_port
3. update_port_precommit
4. update_port_postcommit
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**************
$ neutron net-create test
Created a new network:
| Field | Value |
| admin_state_up | True |
| availability_zone_hints | |
| availability_zones | |
| created_at | 2017-02-15T09:12:13 |
| description | |
| id | dec7e34d-dc64-495c-8da1-2a49a29a4e05 |
| ipv4_address_scope | |
| ipv6_address_scope | |
| mtu | 1450 |
| name | test |
| port_security_enabled | True |
| provider:network_type | vxlan |
| provider:physical_network | |
| provider:segmentation_id | 1022 ...


Revision history for this message
Sahid Orentino (sahid-ferdjaoui) wrote :

Nothing really moved around this and the bug has been opened 6 years old. The code around binding profile moved. Please reopen if needed.

Changed in neutron:
status: New → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.