Open Stack

> Steve Baker <sbaker at redhat.com> wrote on 21.10.2013 23:02:47:
> From: Steve Baker <sbaker at redhat.com>
> To: openstack-dev at lists.openstack.org,
> Date: 21.10.2013 23:06
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
>> On 10/22/2013 08:45 AM, Mike Spreitzer wrote:
>> Steve Baker <sbaker at redhat.com> wrote on 10/15/2013 06:48:53 PM:
>>
>> > I've just written some proposals to address Heat's HOT software
>> > configuration needs, and I'd like to use this thread to get some
feedback:
>> > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
>> > https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-
>> bootstrap-config
>> >
>> > Please read the proposals and reply to the list with any comments or
>> > suggestions.
>>
>> Can you confirm whether I have got the big picture right?  I think
>> some of my earlier remarks were mistaken.
>>
>> You propose to introduce the concept of component and recognize
>> software configuration as a matter of invoking components --- with a
>> DAG of data dependencies among the component invocations.  While
>> this is similar to what today's heat engine does for resources, you
>> do NOT propose that the heat engine will get in the business of
>> invoking components.  Rather: each VM will run a series of component
>> invocations, and in-VM mechanisms will handle the cross-component
>> synchronization and data communication.
> This is basically correct, except that in-VM mechanisms won't know
> much about cross-component synchronization and data communication.
> They will just execute whatever components are available to be
> executed, and report back values to heat-engine by signalling to
> waitconditions.
>>  You propose to add a bit of sugaring for the wait condition&handle
>> mechanism, and the heat engine will do the de-sugaring.
> Yes, I think improvements can be made on what I proposed, such as
> every component signalling when it is complete, and optionally
> including a return value in that signal.

Being able to handle completion of single components inside a VM and being
able to pass outputs of those components seems important to me. I think
that should mostly address the requirements for declaring data dependencies
between components that have been discussed before in this thread. If
wait-conditions are the underlying mechanism, fine, as longs as we can hid
it from the template syntax.

For example, something like this should be possible:

components:
  comp_a:
    type: OS::Heat::SomeCMProvider
    properties:
      prop1: { get_param: param1 }
      prop2: ...
  comp_b:
    type: OS::Heat::SomeCMProvider
    properties:
      propA: { get_attr: [ comp_a, some_attr ] }

resources:
  serverA:
    type: OS::Nova::Server
    # ...
    components:
      - comp_a
  serverB:
    type: OS::Nova::Server
    # ...
    components:
      - comp_b

I.e. there are two components comp_a and comp_b on two different servers.
comp_a has a data dependency on an attribute of comp_b. If we treat
'properties' as input to components and 'attributes' as output (the way it
is currently done for resources), that should be doable.
BTW, the convention of properties being input and attributes being output,
i.e. that subtle distinction between properties and attributes is not
really intuitive, at least not to me as non-native speaker, because I used
to use both words as synonyms.
Anyway it seems like the current proposal is a starting point with
enhancements on the roadmap, right?

>>  Each component is written in one of a few supported configuration
>> management (CM) frameworks, and essentially all component
>> invocations on a given VM invoke components of the same CM framework
>> (with possible exceptions for one or two really basic ones).
> Rather than being limited to a few supported CM tools, I like the
> idea of some kind of provider mechanism so that users or heat admins
> can add support for new CM tools. This implies that it needs to be
> possible to add a component type without requiring custom python
> that runs on heat engine.
>> The heat engine gains the additional responsibility of making sure
>> that the appropriate CM framework(s) is(are) bootstrapped in each VM.
> Maybe. Or it might be up to the user to invoke images that already
> have the CM tools installed, or the user can provide a custom
> component provider which installs the tool in the way that they want.
>
> As for the cross-component synchronization and data communication
> question, at this stage I'm not comfortable with bringing something
> like zookeeper into the mix for a general solution for inter-
> component communication.  If heat engine handles resource
> dependencies and zookeeper handles software configuration
> dependencies this would result in the state of the stack being split
> between two different co-ordination mechanisms.

I think that zookeeper could be an _optional_ backend for this, but using
the current mechanisms in Heat should probably be the primary or default
way of doing this.

>
> We've put quite some effort into heat engine to co-ordinate resource
> dependencies. Wait conditions are currently cumbersome to use, but
> by exposing software configuration state in terms of resource
> dependencies they do enable heat engine to be central source of
> state for the entire stack, including progress of software config.

I agree that the Heat engine should be the master, i.e. also know when
software components are configured (based on the signaling enhancements
discussed earlier). This way I can now for sure that a stack is
CREATE_COMPLETE when I as the Heat engine.

>
> If wait conditions can become palatable to use (or completely
> transparent) then to me that addresses the main concerns about using
> them in the short term. Longer term I'd consider something like
> Marconi to replace metadata polling and wait condition signalling
> but it is too early to be having that
> conversation._______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev