Networks with enabled vlan_transparency can be any of any type available in Neutron (vxlan, vlan, flat in case of Linuxbridge, etc.). In most cases it is fine when packets in such case have ethertype 0x8100 (802.1q).
The same ethertype is configured always for vlan network with vlan_transparent=True. But in such case as we have 2 vlans already (S-Tag and C-Tag) it is really QinQ. Neutron still configures ethertype to be 0x8100 in such case and it works for most of the cases.
But in case of some hardware it needs to be 0x8a88 (802.1ad) which is real QinQ type.
So I think that it would be good to add operators possibility to configure what ethertype will be used in such case.
It could be simple config option and all vlan networks with enabled vlan transparency would use it.
Default value of that option would be 0x8100 to be compatible with what we have now.
i dont really think is is valid.
vlan transparancy and QinQ transparnace are two different things
so really i think you should have two seperate extentions.
if you were to extend it to QinQ then vlan_transparen
the current way that neutron extension are reported is also kind of problematic.
neutron currently reports all available extension not just enabled extensions so you cant as an end user determine if the cloud support an extension by look at the extension list.
you have to actually try to use it which can lead to very strange behaviour due to how the correct port create logic works. on in this case network create.
the response form the api is not guaranteed to match the value in the db depending on how the extension was implemented.
im not sure exposing the Ethernet type as something the operator set is really what we want to do. it really should be configured by the tenant. the operator might want a value to say which ones are allowed but i think it would be better for each ml2 driver to report what it supports and fail to bind ports to then network if it can fullfil that requirement.
it really sucks to get the failure that late but i think that the best approach we could do today.
if the operator has an api level config value like the allowed vnic_types to specify allowed Ethernet types you could reject it at the api level instead.
alternately if you have a separate qinq extension and you only report it if the extension driver is listed then operators can control enabling it via the extension driver config option in the ml2_conf.ini and end-user can detect it by looking at the extension list. this also allows individual ml2 drivers to opt into support.
i think ^ is a much better approach as all the other approach that extend the existing extension are config driver api behaviour that causes interoperate issues between clouds.
e.g. how would you detect if two cloud both support QinQ if you extend the vlan transparency extension instead of adding a new QinQ transparency extension. as an end user you cannot.