[openstack-dev] [Heat] HOT Software orchestration proposal for workflows

Thomas Spatzier thomas.spatzier at de.ibm.com
Mon Oct 14 21:05:29 UTC 2013


Steven Dake <sdake at redhat.com> wrote on 11.10.2013 21:02:38:
> From: Steven Dake <sdake at redhat.com>
> To: OpenStack Development Mailing List
<openstack-dev at lists.openstack.org>,
> Date: 11.10.2013 21:04
> Subject: Re: [openstack-dev] [Heat] HOT Software orchestration
> proposal for workflows
>
> On 10/11/2013 11:55 AM, Lakshminaraya Renganarayana wrote:
> Clint Byrum <clint at fewbar.com> wrote on 10/11/2013 12:40:19 PM:
>
> > From: Clint Byrum <clint at fewbar.com>
> > To: openstack-dev <openstack-dev at lists.openstack.org>
> > Date: 10/11/2013 12:43 PM
> > Subject: Re: [openstack-dev] [Heat] HOT Software orchestration
> > proposal for workflows
> >
> > > 3. Ability to return arbitrary (JSON-compatible) data structure
> from config
> > > application and use attributes of that structure as an input for
other
> > > configs
> >
> > Note that I'd like to see more use cases specified for this ability.
The
> > random string generator that Steve Baker has put up should handle most
> > cases where you just need passwords. Generated key sharing might best
> > be deferred to something like Barbican which does a lot more than Heat
> > to try and keep your secrets safe.
>
> I had seen a deployment scenario that needed more than random string
> generator. It was during the deployment of a system that has
> clustered application servers, i.e., a cluster of application server
> nodes + a cluster manager node. The deployment progresses by all the
> VMs (cluster-manager and cluster-nodes) starting concurrently. Then
> the cluster-nodes wait for the cluster-manager to send them data
> (xml) to configure themselves. The cluster-manager after reading its
> own config file, generates config-data for each cluster-node and
> sends it to them.

> Is the config data per cluster node unique to each node?  If not:

I think Lakshmi's example (IBM WebSphere, right?) talks about a case where
the per cluster member info is unique per member, so the one fits all
approach does not work. In addition, I think there is a constraint that
members must join one by one and cannot join concurrently.

>
> Change deployment to following model:
> 1. deploy cluster-manager as a resource with a waitcondition -
> passing the data using the cfn-signal  -d to send the xml blob
> 2. have cluster nodes wait on wait condition in #1, using data from
> the cfn-signal
>
> If so, join the config data sent in cfn-signal and break it apart by
> the various cluster nodes in #2
> Thanks,
> LN

>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list