On Tue, May 23, 2017 at 3:42 PM, Sean McGinnis <sean.mcgin...@gmx.com> wrote: > >> If it's just too much debt and risk of slippery slope type arguments on >> the Nova side (and that's fair, after lengthy conversations with Nova folks >> I get it), do we consider just orchestrating this from say OpenStack Client >> completely? The last resort (and it's an awful option) is orchestrate the >> whole thing from Cinder. We can certainly make calls to Nova and pass in >> the volume using the semantics that are already accepted and in use. >> >> John >> > > /me runs away screaming!
Now I know Sean's weakness... In this particular case it may not be necessary, but I think early implementation of composite features in clients is actually the right way to prove the utility of these things going forward. Establish and document the process, implement in a way for users to opt-in, and move into the services as they are proven useful. With the magic of microversions we can then migrate from client-side to server-side as the implementations roll through the deployment lifecycle. This last bit is important. Even today many of our users are unable to take advantage of useful features that are already over a year old due to the upgrade delay that production deployments see. Implementing new things in clients helps users on existing clouds. Sure other client implementations are left to their own work, but they should have a common process model to follow, and any choice to deviate from that is their own. dt -- Dean Troyer dtro...@gmail.com __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
