[neutron] Proposal to deprecate and remove vlan_transparent config option
Hi, We have config option to enable vlan_transparent api extension currently. We will also have similar config option for vlan_qinq (it is now proposed in [1]). In both cases we have validation by mechanism drivers if option is or is not supported while networks are created. We can also filter out enabled API extensions by mechanism drivers, see [2] for example. So I proposed [3] to remove that config option and keep API extension to be loaded always if enabled ML2 drivers supports it. But before I will propose patch for that I would like to ask if there is maybe some use case for this config option really and maybe some of you somehow depends on it. In such case maybe we should keep it like it is now and don't remove it. Please let me know if you are using somehow this option. [1] https://review.opendev.org/c/openstack/neutron/+/937372 [2] https://github.com/openstack/neutron/blob/559672f777312d00c4358626650cc577e4... [3] https://bugs.launchpad.net/neutron/+bug/2092174 -- Slawek Kaplonski Principal Software Engineer Red Hat
On 08/01/2025 14:27, Sławek Kapłoński wrote:
Hi,
We have config option to enable vlan_transparent api extension currently. We will also have similar config option for vlan_qinq (it is now proposed in [1]).
In both cases we have validation by mechanism drivers if option is or is not supported while networks are created. We can also filter out enabled API extensions by mechanism drivers, see [2] for example.
So I proposed [3] to remove that config option and keep API extension to be loaded always if enabled ML2 drivers supports it. But before I will propose patch for that I would like to ask if there is maybe some use case for this config option really and maybe some of you somehow depends on it. In such case maybe we should keep it like it is now and don't remove it. Please let me know if you are using somehow this option.
the obvious answer is that even if the backend can supprot it an operator may not want to allow vlan transparent networks for example if they have mutple ml2 driver enabeld and only a subset of them supprot it i.e. if you have both ovn and sriov_nic_agent then wether a netwrok can be transparent or not depens on if all enabel drivers supprot it. correctly me if im wrong but ovn can use q in q to allwo vlan transparent vlan network but the sriov nic agent cannot. if you have not already deprecated the vlan transparent config option in a prior slurp release you also are not allowed to remove it this cycle. looking at https://review.opendev.org/c/openstack/neutron/+/937372/12/neutron/conf/comm... its not marked as deprecated so that is required first. then in 2025.2 you could remove it.
[1] https://review.opendev.org/c/openstack/neutron/+/937372 [2] https://github.com/openstack/neutron/blob/559672f777312d00c4358626650cc577e4...
[3] https://bugs.launchpad.net/neutron/+bug/2092174
--
Slawek Kaplonski
Principal Software Engineer
Red Hat
Hi, Dnia środa, 8 stycznia 2025 18:13:45 czas środkowoeuropejski standardowy Sean Mooney pisze:
On 08/01/2025 14:27, Sławek Kapłoński wrote:
Hi,
We have config option to enable vlan_transparent api extension currently. We will also have similar config option for vlan_qinq (it is now proposed in [1]).
In both cases we have validation by mechanism drivers if option is or is not supported while networks are created. We can also filter out enabled API extensions by mechanism drivers, see [2] for example.
So I proposed [3] to remove that config option and keep API extension to be loaded always if enabled ML2 drivers supports it. But before I will propose patch for that I would like to ask if there is maybe some use case for this config option really and maybe some of you somehow depends on it. In such case maybe we should keep it like it is now and don't remove it. Please let me know if you are using somehow this option.
the obvious answer is that even if the backend can supprot it an operator may not want to allow vlan transparent networks
for example if they have mutple ml2 driver enabeld and only a subset of them supprot it
i.e. if you have both ovn and sriov_nic_agent then wether a netwrok can be transparent or not depens on if all enabel drivers supprot it.
correctly me if im wrong but ovn can use q in q to allwo vlan transparent vlan network but the sriov nic agent cannot.
You are right but the way how the check is implemented now is that it checks on all of the enabled ML2 drivers on the `create_network_precommit` and if any of drivers say that vlan_transparency is not supported, network will not be created.
if you have not already deprecated the vlan transparent config option in a prior slurp release you also are not allowed to remove it this cycle.
looking at https://review.opendev.org/c/openstack/neutron/+/937372/12/neutron/conf/comm... its not marked as deprecated so that is required first.
then in 2025.2 you could remove it.
Yes, of course you are right. That's why I asked about "deprecate and remove" this option where I had removal in the future cycle in mind :)
[1] https://review.opendev.org/c/openstack/neutron/+/937372 [2] https://github.com/openstack/neutron/blob/559672f777312d00c4358626650cc577e4...
[3] https://bugs.launchpad.net/neutron/+bug/2092174
--
Slawek Kaplonski
Principal Software Engineer
Red Hat
-- Slawek Kaplonski Principal Software Engineer Red Hat
Hello: As Sean mentioned, the issue arises when we have multiple backends running (OVS+SRIOV, OVN+SRIOV, etc). But this was already solved in [1]: we can, by default, enable all the extensions (in this case VLAN transparency and QinQ in a closer future). Then, the mech driver initialization will remove the non supported extensions. QinQ, for example, will be removed if any other mech driver is loaded apart from ML2/OVN (once QinQ implementation is merged). I think we can remove the configuration option and just use the already implemented mechanism [2] to discard or not the extension. Regards. [1]https://review.opendev.org/c/openstack/neutron/+/743767 [2]https://bugs.launchpad.net/neutron/+bug/1888829 On Thu, Jan 9, 2025 at 9:35 AM Sławek Kapłoński <skaplons@redhat.com> wrote:
Hi,
Dnia środa, 8 stycznia 2025 18:13:45 czas środkowoeuropejski standardowy Sean Mooney pisze:
On 08/01/2025 14:27, Sławek Kapłoński wrote:
Hi,
We have config option to enable vlan_transparent api extension currently. We will also have similar config option for vlan_qinq (it is now proposed in [1]).
In both cases we have validation by mechanism drivers if option is or is not supported while networks are created. We can also filter out enabled API extensions by mechanism drivers, see [2] for example.
So I proposed [3] to remove that config option and keep API extension to be loaded always if enabled ML2 drivers supports it. But before I will propose patch for that I would like to ask if there is maybe some use case for this config option really and maybe some of you somehow depends on it. In such case maybe we should keep it like it is now and don't remove it. Please let me know if you are using somehow this
option.
the obvious answer is that even if the backend can supprot it an operator may not want to allow vlan transparent networks
for example if they have mutple ml2 driver enabeld and only a subset of them supprot it
i.e. if you have both ovn and sriov_nic_agent then wether a netwrok can be transparent or not depens on if all enabel drivers supprot it.
correctly me if im wrong but ovn can use q in q to allwo vlan transparent vlan network but the sriov nic agent cannot.
You are right but the way how the check is implemented now is that it checks on all of the enabled ML2 drivers on the `create_network_precommit` and if any of drivers say that vlan_transparency is not supported, network will not be created.
if you have not already deprecated the vlan transparent config option in a prior slurp release you also are not allowed to remove it this cycle.
looking at
https://review.opendev.org/c/openstack/neutron/+/937372/12/neutron/conf/comm...
its not marked as deprecated so that is required first.
then in 2025.2 you could remove it.
Yes, of course you are right. That's why I asked about "deprecate and remove" this option where I had removal in the future cycle in mind :)
[1] https://review.opendev.org/c/openstack/neutron/+/937372 [2]
https://github.com/openstack/neutron/blob/559672f777312d00c4358626650cc577e4...
[3] https://bugs.launchpad.net/neutron/+bug/2092174
--
Slawek Kaplonski
Principal Software Engineer
Red Hat
-- Slawek Kaplonski Principal Software Engineer Red Hat
participants (3)
-
Rodolfo Alonso Hernandez
-
Sean Mooney
-
Sławek Kapłoński