Open Stack

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

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131022/ac525f0a/attachment.html>