Open Stack

On 09/26/2015 12:04 AM, Joshua Harlow wrote:
> +1 from me, although I thought heat was supposed to be this thing?
>
> Maybe there should be a 'warm' project or something ;)
>
> Or we can call it 'bbs' for 'building block service' (obviously not
> bulletin board system); ask said service to build a set of blocks into
> well defined structures and let it figure out how to make that happen...
>
> This though most definitely requires cross-project agreement though so
> I'd hope we can reach that somehow (before creating a halfway done new
> orchestration thing that is halfway integrated with a bunch of other
> apis that do one quarter of the work in ten different ways).

Indeed, I don't think I understand what need heat is failing to fulfill 
here? A user can easily have a template that contains a single server 
and a volume.

Heat's job is to be an API that lets you define a result[1] and then 
calls the APIs of whatever projects provide those things.

1: in this case, the result is "a working server with network and storage"

> Duncan Thomas wrote:
>> 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?

-- 
Ryan Brown / Senior Software Engineer, Openstack / Red Hat, Inc.