Comment 8 for bug 1631371

Correct me if I'm reading it wrong, but I think your point (b) is the same as problem (d) in the original post. Which is explicitly and intentionally not addressed here. I'm not arguing for that.

I find your point (a) obviously true. However if we don't expose the (up-to-date) trunk_details over the metadata API then the guest OS does not even have the chance to poll. I'm a bit baffled: Why did we add the option to the trunk port feature to add/remove subports to a running vm, if we don't make the up-to-date information required to bring up a subport available where it is needed?

Are you arguing against the use case and/or against the implementation proposal?

If you accept the use case, then either nova has to be a neutron client reading trunk_details, or neutron has to be a nova client setting some meta-like field. None of these couplings are new. Nova is a heavy neutron client, but AFAICT neutron is also a nova client already when it uses os-external notifications. So I don't see how this proposal would make the nova-neutron coupling stronger than it is now.