Open Stack

I think there's a place for yet another service breakout from nova - some
sort of like-weight platform orchestration piece, nothing as complicated or
complete as heat, nothing that touches the inside of a VM, just something
that can talk to cinder, nova and neutron (plus I guess ironic and whatever
the container thing is called) and work through long running /
cross-project tasks. I'd probably expect it to provide a task style
interface, e.g. a boot-from-new-volume call returns a request-id that can
then be polled for detailed status.

The existing nova API for this (and any other nova APIs where this makes
sense) can then become a proxy for the new service, so that tenants are not
affected. The nova apis can then be deprecated in slow time.

Anybody else think this could be useful?

On 25 September 2015 at 17:12, Andrew Laski <andrew at lascii.com> wrote:

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



-- 
-- 
Duncan Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150926/0b9f5156/attachment.html>