[Openstack] [Heat] Heat supports OpenStack operation

Duan, Li-Gong (Gary@HPServers-Core-OE-PSC) li-gong.duan at hp.com
Tue Jan 20 09:26:39 UTC 2015


Hi Clint,

Thanks for pointing me to software-config/software-deployment.
I'll look at them.

Regards,
Gary

> -----Original Message-----
> From: Clint Byrum [mailto:clint at fewbar.com]
> Sent: Saturday, January 17, 2015 4:11 AM
> To: openstack
> Subject: Re: [Openstack] [Heat] Heat supports OpenStack operation
> 
> Excerpts from Steven Hardy's message of 2015-01-16 01:11:44 -0800:
> > On Fri, Jan 16, 2015 at 08:34:47AM +0000, Duan, Li-Gong (Gary at HPServers-
> Core-OE-PSC) wrote:
> > >    Does Heat support executing an OpenStack operation, such as migrating
> an
> > >    Nova instance, powering off a Nova instance?
> >
> > We call state changes which don't affect the definition of the stack
> > an "action", and we only support suspend and resume at present (e.g
> > heat action-suspend <stack name>)
> >
> > It may be possible to add support for more actions (until now nobody
> > has asked for them), but note it only really makes sense to drive such
> > actions via heat when dependencies/ordering are important.
> >
> > For example, when suspending then resuming a stack containing a
> > WebServer instance and a DatabaseServer instance, you want
> > DatabaseServer to be resumed before WebServer (same order as on stack
> > create)
> >
> > So, it might make sense to have an action which can power-off a whole
> > stack, turning off each nova node in the right order (you could write
> > a little script which does the same thing quite easily though..).
> >
> > It probably doesn't make much sense for heat to support things like
> > migrating an instance, since it's an operation which isn't scoped to
> > the stack and it's dependencies, it's likely an operator wants to
> > migrate a workload off a specific compute node, which is something
> > Heat has no visibility of at all.
> >
> > >    I know currently Heat does a good job on launching cloud cluster or
> > >    application, such as deploying a Nova instance with specified network
> > >    configuration, but not sure how to control(not launch or delete) a Nova
> > >    instance or cinder volume.
> >
> > Right now, the easiest answer is write a little script which uses
> > information from heat (e.g to get the UUID's for the resources you
> > want to
> > control) then e.g calls nova.
> >
> > >    If Heat does not support these OpenStack operation, what is the best
> Heat
> > >    way if we want to execute some operations, such as powering off a
> Nova
> > >    instance, in Heat template?
> >
> > As mentioned above, these lifecycle operations affect the stack state,
> > but not it's definition, so it probably doesn't make sense to expose
> > actions like powering off an instance in the heat template.
> 
> We have discussed in the past adding a target state as a property for servers.
> Right now we only target ACTIVE, but we could certainly target STOPPED and
> issue stops. It makes sense in certain instances.
> 
> That said, I think most of the time you want to use a workflow tool (like
> Ansible or Mistral) to orchestrate actions. Heat can't possibly know all the
> sequencing all services may require before and after a server is stopped. So
> in these instances you either want the workflow tool to drive Heat, or to
> have Heat defer to the workflow tool using software-config/software-
> deployment.
> 
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack




More information about the Openstack mailing list