<div dir="ltr">><span style="font-size:12.8px">I see a clear line between something that handles the creation of all ancillary resources needed to boot a VM and then the creation of the VM itself.</span><div><br></div><div>I agree. To me the line is the difference between creating a top level resource, and adding a host to that resource. </div><div><br></div><div>For example, I do expect a top level compute API to:</div><div>-Request an IP from Neutron</div><div>-Associate an instance with a volume</div><div>-Add an instance to a network security group in Neutron</div><div>-Add a real to a vip in neutron </div><div><br></div><div>But I don't expect Nova to:</div><div>-Create tenant/provider networks in Neutron<br></div><div>-Create a volume (boot from volume is a weird case)</div><div>-Create a neutron security group</div><div>-Create a load balancer</div><div><br></div><div>Also, if Nova is the API for all things compute, then there are some things it will need to support that are not specific to VMs. For example, with Ironic my users expect to use the Nova API/CLI to boot a baremetal compute resource, and specify raid configuration as well as drive layout. My understanding is there has been pushback on adding that to Nova, since it doesn't make sense to have RAID config when building a VM. But, if Nova is the compute abstraction layer, then we'll need a graceful way to express this.</div><div><br></div><div><span style="font-size:12.8px">-James</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 28, 2015 at 9:12 AM, 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/28/15 at 10:19am, Sean Dague wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/28/2015 10:11 AM, Andrew Laski wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/28/15 at 08:50am, Monty Taylor wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 09/28/2015 07:58 AM, Sylvain Bauza wrote:<br>
</blockquote></blockquote>
<snip><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>
Specifically, I want "nova boot" to get me a VM with an IP address. I<br>
don't want it to do fancy orchestration - I want it to not need fancy<br>
orchestration, because needing fancy orchestration to get a VM  on a<br>
network is not a feature.<br>
</blockquote>
<br>
In the networking case there is a minimum of orchestration because the<br>
time required to allocate a port is small.  What has been requiring<br>
orchestration is the creation of volumes because of the requirement of<br>
Cinder to download an image, or be on a backend that support fast<br>
cloning and rely on a cache hit.  So the question under discussion is<br>
when booting an instance relies on another service performing a long<br>
running operation where is a good place to handle that.<br>
<br>
My thinking for a while has been that we could use another API that<br>
could manage those things.  And be the central place you're looking for<br>
to pass a simple "nova boot" with whatever options are required so you<br>
don't have to manage the complexities of calls to<br>
Neutron/Cinder/Nova(current API).  What's become clear to me from this<br>
thread is that people don't seem to oppose that idea, however they don't<br>
want their users/clients to need to switch what API they're currently<br>
using(Nova).<br>
<br>
The right way to proceed with this idea seems to be to by evolving the<br>
Nova API and potentially creating a split down the road.  And by split I<br>
more mean architectural within Nova, and not necessarily a split API.<br>
What I imagine is that we follow the model of git and have a plumbing<br>
and porcelain API and each can focus on doing the right things.<br>
</blockquote>
<br>
Right, and I think that's a fine approach. Nova's job is "give me a<br>
working VM". Working includes networking, persistent storage. The API<br>
semantics for "give me a working VM" should exist in Nova.<br>
<br>
It is also fine if there are lower level calls that tweak parts of that,<br>
but nova boot shouldn't have to be a multi step API process for the<br>
user. Building one working VM you can do something with is really the<br>
entire point of Nova.<br>
</blockquote>
<br></div></div>
What I'm struggling with is where do we draw the line in this model?  For instance we don't allow a user to boot an instance from a disk image on their local machine via the Nova API, that is a multi step process.  And which parameters do we expose that can influence network and volume creation, if not all of them?  It would be helpful to establish guidelines on what is a good candidate for inclusion in Nova.<br>
<br>
I see a clear line between something that handles the creation of all ancillary resources needed to boot a VM and then the creation of the VM itself.  I don't understand why the creation of the other resources should live within Nova but as long as we can get to a good split between responsibilities that's a secondary concern.<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>
        -Sean<br>
<br>
-- <br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><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>
</blockquote>
<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></div>