<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 23, 2017 at 3:43 PM, Dean Troyer <span dir="ltr"><<a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, May 23, 2017 at 3:42 PM, Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com">sean.mcginnis@gmx.com</a>> wrote:<br>
><br>
>> If it's just too much debt and risk of slippery slope type arguments on<br>
>> the Nova side (and that's fair, after lengthy conversations with Nova folks<br>
>> I get it), do we consider just orchestrating this from say OpenStack Client<br>
>> completely?  The last resort (and it's an awful option) is orchestrate the<br>
>> whole thing from Cinder.  We can certainly make calls to Nova and pass in<br>
>> the volume using the semantics that are already accepted and in use.<br>
>><br>
>> John<br>
>><br>
><br>
> /me runs away screaming!<br>
<br>
</span>Now I know Sean's weakness...<br></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​Ha!  I thought it was the put it in Cinder part (so I have a patch queued up for emergencies when I need to threaten him). :)</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In this particular case it may not be necessary, but I think early<br>
implementation of composite features in clients is actually the right<br>
way to prove the utility of these things going forward.  </blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​Yeah, I've been doing more with OSC as of late and it really has all the pieces and currently is one of the few places in OpenStack that really knows what the other actors are up to (or at least how to communicate with them and ask them to do things). </div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">It does seem like a reasonable place (OSC), and as far as some major objections I've heard already around "where would you draw the line"... yeah, that's important.  To start though orchestrated "features" that have been requested for multiple releases that are actually fairly trivial to implement might be a great starting point.  It's at least worth thinking on for a bit in my opinion.</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">​</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Establish and<br>
document the process, implement in a way for users to opt-in, and move<br>
into the services as they are proven useful.  With the magic of<br>
microversions we can then migrate from client-side to server-side as<br>
the implementations roll through the deployment lifecycle.<br>
<br>
This last bit is important.   Even today many of our users are unable<br>
to take advantage of useful features that are already over a year old<br>
due to the upgrade delay that production deployments see.<br>
Implementing new things in clients helps users on existing clouds.<br>
Sure other client implementations are left to their own work, but they<br>
should have a common process model to follow, and any choice to<br>
deviate from that is their own.<br>
<span class="HOEnZb"><font color="#888888"><br>
dt<br>
<br>
--<br>
<br>
Dean Troyer<br>
<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>