[Neutron] ML2: Can Operators Safely Extend binding:profile with Custom Keys?
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 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. My intent is to: - Create a custom API endpoint that allows reading and updating specific key/value pairs in this JSON dictionary. - 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?** 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
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
Greetings, Sean had some great points below, but I'm going to put a slightly finer point on some of the items from the Ironic point of view. If you'd like to discuss any of this in a high bandwidth discussion, please let me know. The rest of my comments are in-line, below. Thanks! -Julia On Wed, Jul 30, 2025 at 9:57 AM Sean Mooney <smooney@redhat.com> wrote:
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
It might help the discussion to understand the "why". What challenge are you trying to solve?
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
As Sean notes below, Nova, Ironic, and Zun pass binding information for specific port binding details, which the services either have (hopefully with access/data model restrictions), can generate, or are aware of through an operator also knowing the requirements of the ML2 plugin on the backend. The key being, more so what the ML2 plugin expects. For VM workloads, that is fairly standardized. For baremetal ports, that is distinctly different and is also generally standardized, however the ML2 plugin ends up defining what it expects/requires so there can be some variation based upon the ML2 plugin's expectations. That being said, we don't expect a need to update those values, and I think as a maintainer of Ironic I'd really like to understand the base need behind being able to modify and manage port binding details outside of a service's workflows. Potentially that could create a security issue if a member in a project could just change the information as it relates to one of the port bindings created inside of that project. For example, what if an ML2 plugin is loaded and able to configure the switching infrastructure and a malicious user knows port TenGig2/18 is the accounting department database servers' backup interface and that they wish to attach it to a network they control. Obviously, I would encourage caution and a complete understanding of the driving need should Neutron decide this is a path to pursue.
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.
++ I *think* I've seen an instance of this in the wild with a 3rd party plugin over the years, but do agree since the caller of the port attachment API should know best in large part because it operates with a particular risk and attack profile, and the overall idea denoted by the intent below could become problematic depending on all of the details.
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
In the case of Ironic, and I think in general terms of the binding profile data persisting across upgrades and database migrations, it would be advisable to keep it. Some ML2 plugins *do* also have concepts of enforcing eventual consistency to help prevent configuration drift of switching infrastructure, and so the configurations then *do* get revisited. Removing the data may break the plugin. Furthermore, it can be extremely helpful when troubleshooting for a cloud operator to be able to consult the data in the field and then validate it on the backend. Granted, I suspect that is uncommon on VM workloads, but for baremetal workloads it can provide insight which is super valuable to identify a root cause.
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
On 31/07/2025 15:56, Julia Kreger wrote:
Greetings,
Sean had some great points below, but I'm going to put a slightly finer point on some of the items from the Ironic point of view. If you'd like to discuss any of this in a high bandwidth discussion, please let me know.
The rest of my comments are in-line, below.
Thanks!
-Julia
On Wed, Jul 30, 2025 at 9:57 AM Sean Mooney <smooney@redhat.com> wrote:
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
It might help the discussion to understand the "why". What challenge are you trying to solve?
ya this is i think the imporant thing to capture. there may be a more supprotable wya to achive this.
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
As Sean notes below, Nova, Ironic, and Zun pass binding information for specific port binding details, which the services either have (hopefully with access/data model restrictions), can generate, or are aware of through an operator also knowing the requirements of the ML2 plugin on the backend. The key being, more so what the ML2 plugin expects. For VM workloads, that is fairly standardized. For baremetal ports, that is distinctly different and is also generally standardized, however the ML2 plugin ends up defining what it expects/requires so there can be some variation based upon the ML2 plugin's expectations. That being said, we don't expect a need to update those values, and I think as a maintainer of Ironic I'd really like to understand the base need behind being able to modify and manage port binding details outside of a service's workflows. Potentially that could create a security issue if a member in a project could just change the information as it relates to one of the port bindings created inside of that project. For example, what if an ML2 plugin is loaded and able to configure the switching infrastructure and a malicious user knows port TenGig2/18 is the accounting department database servers' backup interface and that they wish to attach it to a network they control.
Obviously, I would encourage caution and a complete understanding of the driving need should Neutron decide this is a path to pursue.
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.
++ I *think* I've seen an instance of this in the wild with a 3rd party plugin over the years, but do agree since the caller of the port attachment API should know best in large part because it operates with a particular risk and attack profile, and the overall idea denoted by the intent below could become problematic depending on all of the details.
My intent is to: - Create a custom API endpoint that allows reading and updating specific key/value pairs in this JSON dictionary.
- 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 In the case of Ironic, and I think in general terms of the binding
you shoudl use the binding:details for that instead or ideally a dedicated extension. profile data persisting across upgrades and database migrations, it would be advisable to keep it. Some ML2 plugins *do* also have concepts of enforcing eventual consistency to help prevent configuration drift of switching infrastructure, and so the configurations then *do* get revisited. Removing the data may break the plugin. Furthermore, it can be extremely helpful when troubleshooting for a cloud operator to be able to consult the data in the field and then validate it on the backend. Granted, I suspect that is uncommon on VM workloads, but for baremetal workloads it can provide insight which is super valuable to identify a root cause.
nova is free to delete any keys form it at any time.
i should also clarify my repsonce. neutron i expected to persevere the content of binding:profile across db migrations and upgrades as it is not allow to modify the content. my no was for the first half ```Are operators and third-party ML2 drivers free to add arbitrary key/value pairs to the `binding:profile` dictionary``` operators and third-party ML2 drivers are both not allowed to modify the `binding:profile`. we rely on the fact that nothing can change this to orchestrate live migration properly between nova and neutron for example to tell the neutron backend what host we will be migrating too. this was a little hyperbolic its true but we actually are careful not to clobber the info in general, if there was a collision between keys or your API was used to modify the state of a key used by nova like the migrate_to or pci_slot keys it could cause a security issue or break move operations. that is why this files is intended to only be modified with the service role and why it was previously admin only. it hold important internal state that is required for nova/ironic and the network backned to function safely. Julia touched on that above in there response as well with the example of someone guessing or modifying the TOR switch port name `TenGig2/18`
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
participants (3)
-
cxue22＠bloomberg.net
-
Julia Kreger
-
Sean Mooney