Steven Dake <sd...@redhat.com> wrote on 11.10.2013 21:02:38: > From: Steven Dake <sd...@redhat.com> > To: OpenStack Development Mailing List <openstack-dev@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 <cl...@fewbar.com> wrote on 10/11/2013 12:40:19 PM: > > > From: Clint Byrum <cl...@fewbar.com> > > To: openstack-dev <openstack-dev@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
