© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
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.