<div dir="ltr">I think there's a place for yet another service breakout from nova - some sort of like-weight platform orchestration piece, nothing as complicated or complete as heat, nothing that touches the inside of a VM, just something that can talk to cinder, nova and neutron (plus I guess ironic and whatever the container thing is called) and work through long running / cross-project tasks. I'd probably expect it to provide a task style interface, e.g. a boot-from-new-volume call returns a request-id that can then be polled for detailed status.<div><br></div><div>The existing nova API for this (and any other nova APIs where this makes sense) can then become a proxy for the new service, so that tenants are not affected. The nova apis can then be deprecated in slow time.</div><div><br></div><div>Anybody else think this could be useful?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 September 2015 at 17:12, Andrew Laski <span dir="ltr"><<a href="mailto:andrew@lascii.com" target="_blank">andrew@lascii.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 09/24/15 at 03:13pm, James Penick wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
At risk of getting too offtopic I think there's an alternate solution to<br>
doing this in Nova or on the client side. I think we're missing some sort<br>
of OpenStack API and service that can handle this. Nova is a low level<br>
infrastructure API and service, it is not designed to handle these<br>
orchestrations. I haven't checked in on Heat in a while but perhaps this<br>
is a role that it could fill.<br>
<br>
I think that too many people consider Nova to be *the* OpenStack API when<br>
considering instances/volumes/networking/images and that's not something I<br>
would like to see continue. Or at the very least I would like to see a<br>
split between the orchestration/proxy pieces and the "manage my<br>
VM/container/baremetal" bits<br>
</blockquote>
<br>
<br>
(new thread)<br>
You've hit on one of my biggest issues right now: As far as many deployers<br>
and consumers are concerned (and definitely what I tell my users within<br>
Yahoo): The value of an OpenStack value-stream (compute, network, storage)<br>
is to provide a single consistent API for abstracting and managing those<br>
infrastructure resources.<br>
<br>
Take networking: I can manage Firewalls, switches, IP selection, SDN, etc<br>
through Neutron. But for compute, If I want VM I go through Nova, for<br>
Baremetal I can -mostly- go through Nova, and for containers I would talk<br>
to Magnum or use something like the nova docker driver.<br>
<br>
This means that, by default, Nova -is- the closest thing to a top level<br>
abstraction layer for compute. But if that is explicitly against Nova's<br>
charter, and Nova isn't going to be the top level abstraction for all<br>
things Compute, then something else needs to fill that space. When that<br>
happens, all things common to compute provisioning should come out of Nova<br>
and move into that new API. Availability zones, Quota, etc.<br>
</blockquote>
<br></div></div>
I do think Nova is the top level abstraction layer for compute. My issue is when Nova is asked to manage other resources. There's no API call to tell Cinder "create a volume and attach it to this instance, and create that instance if it doesn't exist." And I'm not sure why the reverse isn't true.<br>
<br>
I want Nova to be the absolute best API for managing compute resources. It's when someone is managing compute and volumes and networks together that I don't feel that Nova is the best place for that. Most importantly right now it seems that not everyone is on the same page on this and I think it would be beneficial to come together and figure out what sort of workloads the Nova API is intending to provide.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-James<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>-- <br>Duncan Thomas</div></div></div>
</div>