Open Stack

Le 25/09/2015 16:12, Andrew Laski a écrit :
> On 09/24/15 at 03:13pm, James Penick wrote:
>>>
>>>
>>> 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.
>
> 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.
>
> 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.

I totally agree with you on those points :
  - nova API should be only supporting CRUD operations for compute VMs 
and should no longer manage neither volumes nor networks IMHO, because 
it creates more problems than it resolves
  - given the above, nova API could possibly accept resources from 
networks or volumes but only for placement decisions related to instances.

Tho, I can also understand that operators sometimes just want a single 
tool for creating this kind of relationship between a volume and an 
instance (and not provide a YAML file), but IMHO, it doesn't perhaps 
need a top-level API, just a python client able to do some very simple 
orchestration between services, something like openstack-client.

I don't really see a uber-value for getting a proxy API calling Nova or 
Neutron. IMHO, that should still be done by clients, not services.

-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
>
>
> __________________________________________________________________________ 
>
> 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