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