© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
A recent RFE [1] was marked as a duplicate of this one. While I agree these RFEs are related (as is [2]), I don't necessary agree that [1] is a duplicate of this RFE; therefore I'm hoping we can consolidate all these RFEs into one workstream.
In particular what's missing in this RFE that's covered in [1] is a means for admins to have more visibility into neutron resource <-> backend resource (realization) mappings, including identification and remediation of lost / orphaned backend resource object scenarios. Our customers are asking for it, and google-foo suggests others are as well.
My current thought is that resource mapping approach [1] (or some variation of it) can be used as a foundation for additional admin / ops types of functionality such as those outlined in this RFE. I've outlined an approach in [3] that uses [1] as a basis for the functionality contained in this RFE and I believe it can help us model more complex relationships than whats exposed via neutron top-level resources today.
Note: if you want to see how [1] works in action, you can watch the video demo [4]... Popcorn recommended, but not required.
Does it make sense to consolidate our discussions on this one to the etherpad [3]?? And perhaps on IRC.
[1] https:/
[2] https:/
[3] https:/
[4] https:/