Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150925/7a572429/attachment.html>