Comment 9 for bug 1636485
Revision history for this message
| Armando Migliaccio (armando-migliaccio) wrote | #9 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f33e652
(Get the code!)
There are four ways to fix this issue, none of them worth the effort, and side effects IMO:
1) Fix it in Nova: Nova looks at device_id before scheduling an instance with a given port. Since the trunk layer sets the device_owner of subports, Nova could be extended to look at device_owner too. This is not ideal because the behavior change is non backward compatible and to go over a micro-versioning bump of the API it's just too much effort for the issue being solved.
2) Fix it in Neutron: there are a few options:
2.1) fix it at the policy layer: nova boot translates into a port binding update of the host_id. The update could be prevented by means of a policy rule as attempted in #5, but this requires changes to the policy engine, and furthermore it could be overruled by a change in policy.json, so not ideal.
2.2) update device attributes server-side whenever a port is added/removed as subport. This has performance implications as observed in #8, in that it makes the trunk API much slower.
2.3) update device attributes driver/agent-side whenever a port is ack-ed. This is similar to 2.2) if device attributes were updated in a background task. This is racy in that there's a window where a boot request can still sneak through. Besides it would end up being driver dependent.
2.4) This is a slight variation of 2.1, but rather than preventing this at the policy engine layer, we could implement this business rule by means of a DB or registry callback. Every time a port is updated, we'd look up if the port participates in a trunk and if so, prevent the operation. This is not only expensive (port update is possibly one of the most used APIs), but it defers the failure mode of the boot process all the way down to nova-compute so the user will end up being with a VM stuck in error state, and this is not much better than booting a VM with an undetermined dataplane (as this report claims).
All in all, I have given this quite a bit of thought, we gained rally testing [1] and tried a couple of alternatives, but none of them were successful. Given the severity, I'd lean to make sure we document this behavior and mark this as won't fix. The cost of addressing this outweighs the benefit in my opinion.
[1] https:/