<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 10:13 AM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@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 5/23/2017 9:56 AM, Duncan Thomas wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is it entirely unreasonable to turn the question around and ask why, given it is such a commonly requested feature, the Nova team are so resistant to it?<br>
</blockquote>
<br></span>
Because it's technical debt for one thing. Adding more orchestration adds complexity, which adds bugs. Also, as noted in the linked devref on this, when nova proxies something via the compute API to another service's API, if that other service changes their API (like with nova's image proxy API to glance v1 for example, and needing to get to glance v2), then we have this weird situation with compatibility. Which is more technical debt. Microversions should make that less of an issue, but it's still there.<br>
<br>
It's also a slippery slope. Once you allow proxies and orchestration into part of the API, people use it as grounds for justifying doing more of it elsewhere, i.e. if we do this for volumes, when are we going to start seeing people asking for passing more detailed information about Neutron ports when creating a server?<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><div class="gmail_default" style="font-family:monospace,monospace">​I get the concern about adding more orchestration etc, I'm not totally convinced only because it's adding another flag as opposed to functionality etc.  But, regardless I get the argument and the slippery slope after talking through it with Matt and Dan multiple times.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">The disappointing part of this for me is that the main reason this comes up (I believe) is not only because Cinder volumes are AWESOME!  But, probably more accurately; all of the non-OpenStack public clouds behave this way (or the big ones do at least).  Service Providers using OpenStack as well as user consuming OpenStack have voiced that they'd like to have this same functionality/behavior that includes selecting what type of volume.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">John</div></div></div>