On 30/07/2025 16:44, cxue22@bloomberg.net wrote:
Hi all,
I'm working on a Neutron customization to expose and manage data in the `binding:profile` field stored in the `ml2_port_bindings` table, and I have a few questions around operator and third-party plugin compatibility — particularly in reference to the blueprint: https://blueprints.launchpad.net/neutron/+spec/ml2-binding-profile
the binding:profile filed is reserved for passing infroamtion from nova to the network backend and neutron ml2 dirver are not allow to modify it this is documetned in the exteions https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definit... the binding details field is owned by neutron https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definit... and can be exteded with other infromation.
As I understand it, the `binding:profile` is represented as a string column containing a JSON dictionary that can be passed by the compute agent and interpreted by ML2 mechanism drivers during port binding.
correct it resesved for use by nova ironic and zun to pass info to the network backend. ml2 dirver shoudl not modify it content.
My intent is to: - Create a custom API endpoint that allows reading and updating specific key/value pairs in this JSON dictionary.
you shoudl use the binding:details for that instead or ideally a dedicated extension.
- Enable third-party mechanism drivers and operators to add custom fields to this profile.
My main question is: **Are operators and third-party ML2 drivers free to add arbitrary key/value pairs to the `binding:profile` dictionary, and can those be expected to persist across Neutron upgrades and database migrations?**
no nova is free to delete any keys form it at any time. we generally try not do becuase we know some vendor driver in the past broke the api contract but you shoudl not buidl any new code in neutron to modify this filed. the binding:details is also a JSON dictionary that can have arbiaty extra metadta the diference is it is the place for ml2 dirver or core plugins to store any additnal metadata that they required.
Additionally: - Are there any best practices or expectations around namespacing or schema validation of custom fields in `binding:profile`? - Are there known caveats or upgrade scenarios where such data may be truncated, filtered, or overwritten?
I'd appreciate any guidance from the Neutron community on how this field is intended to be extended or preserved, and whether such customization is supported in the long term.
Thanks in advance!
Best regards, Chang Xue Bloomberg Engineering