Le 25/09/2015 00:13, James Penick a écrit :
At risk of getting too offtopic I think there's an alternate
solution to doing this in Nova or on the client side. I think
we're missing some sort of OpenStack API and service that can
handle this. Nova is a low level infrastructure API and service,
it is not designed to handle these orchestrations. I haven't
checked in on Heat in a while but perhaps this is a role that it
could fill.
I think that too many people consider Nova to be *the* OpenStack
API when considering instances/volumes/networking/images and
that's not something I would like to see continue. Or at the very
least I would like to see a split between the orchestration/proxy
pieces and the "manage my VM/container/baremetal" bits
(new thread)
You've hit on one of my biggest issues right now: As far as many
deployers and consumers are concerned (and definitely what I tell my
users within Yahoo): The value of an OpenStack value-stream (compute,
network, storage) is to provide a single consistent API for
abstracting and managing those infrastructure resources.
Take networking: I can manage Firewalls, switches, IP selection, SDN,
etc through Neutron. But for compute, If I want VM I go through Nova,
for Baremetal I can -mostly- go through Nova, and for containers I
would talk to Magnum or use something like the nova docker driver.
This means that, by default, Nova -is- the closest thing to a top
level abstraction layer for compute. But if that is explicitly against
Nova's charter, and Nova isn't going to be the top level abstraction
for all things Compute, then something else needs to fill that space.
When that happens, all things common to compute provisioning should
come out of Nova and move into that new API. Availability zones,
Quota, etc.
There is an old story that I would like to see where a nova boot could
have some affinity with volumes and networks. That means that Neutron
and Cinder could provide some resources to the nova scheduler (or nova
could call the projects) so that we could use either filters (for hard
limits) or weighers (for soft limits) in order to say "eh, Nova, please
create me an instance with that flavor and that image close to this
volume or this network".
That said, we still have lots of work to do in Nova to help those
projects giving resources and we agreed to first work on the scheduler
interfaces (for providing resources and for getting a destination)
before working on cross-project resources. That's still an on-going work
but we hope to land the new interfaces by Mitaka.
Not sure if we could have some discussion at Tokyo between Cinder,
Neutron and Nova about how to provide resources to the nova scheduler
given we haven't yet finished the interface reworking, but we could at
least get feedback from the Neutron and Cinder teams about what kind of
resources they'd like to provide so that an user could ask for.
Thoughts on that ?
-Sylvain
-James
__________________________________________________________________________
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
__________________________________________________________________________
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
