Le 28/09/2015 16:19, Sean Dague a écrit :
On 09/28/2015 10:11 AM, Andrew Laski wrote:
On 09/28/15 at 08:50am, Monty Taylor wrote:
On 09/28/2015 07:58 AM, Sylvain Bauza wrote:
<snip>
Specifically, I want "nova boot" to get me a VM with an IP address. I
don't want it to do fancy orchestration - I want it to not need fancy
orchestration, because needing fancy orchestration to get a VM on a
network is not a feature.
In the networking case there is a minimum of orchestration because the
time required to allocate a port is small. What has been requiring
orchestration is the creation of volumes because of the requirement of
Cinder to download an image, or be on a backend that support fast
cloning and rely on a cache hit. So the question under discussion is
when booting an instance relies on another service performing a long
running operation where is a good place to handle that.
My thinking for a while has been that we could use another API that
could manage those things. And be the central place you're looking for
to pass a simple "nova boot" with whatever options are required so you
don't have to manage the complexities of calls to
Neutron/Cinder/Nova(current API). What's become clear to me from this
thread is that people don't seem to oppose that idea, however they don't
want their users/clients to need to switch what API they're currently
using(Nova).
The right way to proceed with this idea seems to be to by evolving the
Nova API and potentially creating a split down the road. And by split I
more mean architectural within Nova, and not necessarily a split API.
What I imagine is that we follow the model of git and have a plumbing
and porcelain API and each can focus on doing the right things.
Right, and I think that's a fine approach. Nova's job is "give me a
working VM". Working includes networking, persistent storage. The API
semantics for "give me a working VM" should exist in Nova.
It is also fine if there are lower level calls that tweak parts of that,
but nova boot shouldn't have to be a multi step API process for the
user. Building one working VM you can do something with is really the
entire point of Nova.
I'm all for a request with some network and volume semantics in it,
which would imply that the Nova scheduler would be able to do some
instance placement based on cross-project resources.
What is a grey line to me is the fact that "give me a volume-backed
instance from this image" requires some volume creation to get it done.
So, if we consider that Nova is the best API for it (and I can
understand the motivation for it), then we need some clear architectural
segmentation between Nova and the other projects in Nova, like Andrew
said (sorry if you feel I'm paraphrasing). For example, the move to
os-brick is one of the efforts we should do, but it's just one step,
since we should decouple all the tasks involved in the instance creation
to isolate those in a better way).
-Sylvain
-Sean
__________________________________________________________________________
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
