On 10/22/2013 08:45 AM, Mike Spreitzer wrote: > Steve Baker <sba...@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.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
