Re: [openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration

[Thomas Spatzier]

Hi Steve,

I have added something to the design summit etherpad at [1] based on this
ML discussion so far. I removed some items from my initial post since they
seem to be resolved. I copied more concrete points from this thread into
other items. Please have a look and edit as needed.

[1] https://etherpad.openstack.org/p/juno-summit-heat-sw-orch

Regards,
Thomas

Steve Baker sba...@redhat.com wrote on 28/04/2014 23:31:56:

 From: Steve Baker sba...@redhat.com
 To: openstack-dev@lists.openstack.org
 Date: 28/04/2014 23:32
 Subject: Re: [openstack-dev] [Heat] Design summit preparation - Next
 steps for Heat Software Orchestration

 On 29/04/14 01:41, Thomas Spatzier wrote:
  Excerpts from Steve Baker's message on 28/04/2014 01:25:29:
 
  I'm with Clint on this one. Heat-engine cannot know the true state
  of a server just by monitoring what has been polled and signaled.
  Since it can't know it would be dangerous for it to guess. Instead
  it should just offer all known configuration data to the server and
  allow the server to make the decision whether to execute a config
  again. I still think one more derived input value would be useful to
  help the server to make that decision. This could either be a
  datestamp for when the derived config was created, or a hash of all
  of the derived config data.
  So as I said in another note, I agree that the this seems best handled
in
  the in-instance tool and the Heat engine, or the resource should
probably
  not have any new magic. If there is some additional state property that
the
  resource maintains, and the in-instance tool handles it, that should be
  fine. I think what is important, is that users who want to use existing
  automation scripts do not have to implement much logic for interpreting
  that additional flag, but that we handle it in the generic hook
  invocation logic.
 
  Can you elaborate more on what you have in mind with the additional
derived
  input value?
 
 Heat needs to give the hook or the config script enough information to
 know whether that *particular* combination of config script + input
 values has been executed on that server. It could do this by providing
 the timestamp or the hash of the derived config, then this piece of
 information can be compared with some local state on the server to
 decide whether to run the config again. Actually the hash could be
 calculated on the server too, so the hash could be calculated in
 55-heat-config then consumed by the hook or config script.
 
  For this design session I have my own list of items to discuss:
  #4.1 Maturing the puppet hook so it can invoke more existing puppet
  scripts
  #4.2 Make progress on the chef hook, and defining the mapping from
  chef concepts to heat config/inputs/outputs
  #4.3 Finding volunteers to write hooks for Salt, Ansible
  #5.1 Now that heatclient can include binary files, discuss enhancing
  get_file to zip the directory contents if it is pointed at a directory
  #5.2 Now that heatclient can include binary files, discuss making
  stack create/update API calls multipart/form-data so that proper
  mime data can be captured for attached files
  #6.1 Discuss options for where else metadata could be polled from (ie,
  swift)
  #6.2 Discuss whether #6.1 can lead to software-config that can work
  on an OpenStack which doesn't allow admin users or keystone domains
  (ie, rackspace)
  #4.1 thru #4.3 are important and seem straight forward and more about
  finding people to do it. If there are design issues to be figured out,
  maybe we can do it offline via the ML.
 
  #5.1 and #5.2 are really interesting and map to use cases we have also
seen
  internally. Is there a size limit for the binaries? Would this also
cover,
  e.g. sending small binaries like a wordpress install tgz instead of
doing a
  yum based install? Or would the latter be something to address via #6
  below?
 
  #6 looks very interesting as well. We also thought about using swift
not
  only for metadata but also for sharing installables to instances in
cases
  where direct download from the internet, for example, is not possible.
 We'll just have to try it to find out were the limits are, but in
 general I would assume the following:
 * user_data limited to about 16k total, so anything bigger than that
 needs to go in the deployment input_values
 * practically speaking, a binary could go in a deployment input value or
 a swift object resource (which doesn't exist yet) to be passed to the
 deployment input value by url
 * The default heat.conf max_template_size=524288, so to avoid this limit
 binaries should be put into swift outside the scope of heat, and passed
 into the template as a parameter URL.


 ___
 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

Re: [openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration

[Thomas Spatzier]

Excerpts from Steve Baker's message on 28/04/2014 01:25:29:

snip
 #1 Enable software components for full lifecycle:
snip
 So in a short, stripped-down version, SoftwareConfigs could look like

 my_sw_config:
   type: OS::Heat::SoftwareConfig
   properties:
 create_config: # the hook for software install
 suspend_config: # hook for suspend action
 resume_config: # hook for resume action
 delete_config: # hook for delete action

snip

 OS::Heat::SoftwareConfig itself needs to remain ignorant of heat
 lifecycle phases, since it is just a store of config.

Sure, I agree on that. SoftwareConfig is just a store of config that gets
used by another resource which then deals with Heat's lifecycle.
The thing I was proposing is actually not making it lifecycle aware, but it
allows the user to store respective config pieces to later be executed by a
software deployment at respective lifecycle steps.


 Currently there are 2 ways to build configs which are lifecycle aware:
 1. have a config/deployment pair, each with different deployment actions
 2. have a single config/deployment, and have the config script do
 conditional logic
on the derived input value deploy_action

 Option 2. seem reasonable for most cases, but having an option which
 maps better to TOSCA would be nice.

So option 2 sounds like the right thing to me. The only things is that I
would not want to put all logic into a large script with conditional
handling, but to allow breaking the script into parts and let the condition
handling be done by the framework. My snippet above would then just allow
for telling the deploy logic which script to call when.
Most of the real work would probably be done in the in-instance tool, so
the Heat resource would really just allow for storing data in a
well-defined structure.


 Clint's StructuredConfig example would get us most of the way there,
 but a dedicated config resource might be easier to use.

Right, and that's the core of my proposal: having a dedicated config
resource that is intuitive to use for template authors.

 The deployment resource could remain agnostic to the contents of this
 resource though. The right place to handle this on the deployment
 side would be in the orc script 55-heat-config, which could infer
 whether the config was a lifecycle config, then invoke the required
 config based on the value of deploy_action.

Fully agree on that. This should be the place to handle most of the work.
I think we are saying the same thing on this topic, so I am optimistic to
agree on a solution :-)



 #2 Enable add-hoc actions on software components:
snip

 Lets park this for now. Maybe one day heat templates will be used to
 represent workflow tasks, but this isn't directly related to software
config.

I think if we get to a good conclusion of #1, maybe this won't be a big
deal after all.
So yeah, maybe park it (but keep in the back of our heads) and look at it
again depending on what the result for #1 looks like.


snip
 #3.1 software deployment should run just once:
 A bug has been raised because with today's implementation it can happen
 that SoftwareDeployments get executed multiple times. There has been some
 discussion around this issue but no final conclusion. An average user
will
 however assume that his automation gets run only or exactly once. When
 using existing scripts, it would be an additional burden to require
 rewrites to cope with multiple invocations. Therefore, we should have a
 generic solution to the problem so that users do not have to deal with
this
 complex problem.

 I'm with Clint on this one. Heat-engine cannot know the true state
 of a server just by monitoring what has been polled and signaled.
 Since it can't know it would be dangerous for it to guess. Instead
 it should just offer all known configuration data to the server and
 allow the server to make the decision whether to execute a config
 again. I still think one more derived input value would be useful to
 help the server to make that decision. This could either be a
 datestamp for when the derived config was created, or a hash of all
 of the derived config data.

So as I said in another note, I agree that the this seems best handled in
the in-instance tool and the Heat engine, or the resource should probably
not have any new magic. If there is some additional state property that the
resource maintains, and the in-instance tool handles it, that should be
fine. I think what is important, is that users who want to use existing
automation scripts do not have to implement much logic for interpreting
that additional flag, but that we handle it in the generic hook
invocation logic.

Can you elaborate more on what you have in mind with the additional derived
input value?



 #3.2 dependency on heat-cfn-api:
 Some parts of current signaling still depend on the heat-cfn-api. While
 work seems underway to completely move to Heat native signaling, some
 cleanup to make sure this is used throughout the code.

Re: [openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration

[Steve Baker]

On 29/04/14 01:41, Thomas Spatzier wrote:
 Excerpts from Steve Baker's message on 28/04/2014 01:25:29:

 I'm with Clint on this one. Heat-engine cannot know the true state
 of a server just by monitoring what has been polled and signaled.
 Since it can't know it would be dangerous for it to guess. Instead
 it should just offer all known configuration data to the server and
 allow the server to make the decision whether to execute a config
 again. I still think one more derived input value would be useful to
 help the server to make that decision. This could either be a
 datestamp for when the derived config was created, or a hash of all
 of the derived config data.
 So as I said in another note, I agree that the this seems best handled in
 the in-instance tool and the Heat engine, or the resource should probably
 not have any new magic. If there is some additional state property that the
 resource maintains, and the in-instance tool handles it, that should be
 fine. I think what is important, is that users who want to use existing
 automation scripts do not have to implement much logic for interpreting
 that additional flag, but that we handle it in the generic hook
 invocation logic.

 Can you elaborate more on what you have in mind with the additional derived
 input value?

Heat needs to give the hook or the config script enough information to
know whether that *particular* combination of config script + input
values has been executed on that server. It could do this by providing
the timestamp or the hash of the derived config, then this piece of
information can be compared with some local state on the server to
decide whether to run the config again. Actually the hash could be
calculated on the server too, so the hash could be calculated in
55-heat-config then consumed by the hook or config script.

 For this design session I have my own list of items to discuss:
 #4.1 Maturing the puppet hook so it can invoke more existing puppet
 scripts
 #4.2 Make progress on the chef hook, and defining the mapping from
 chef concepts to heat config/inputs/outputs
 #4.3 Finding volunteers to write hooks for Salt, Ansible
 #5.1 Now that heatclient can include binary files, discuss enhancing
 get_file to zip the directory contents if it is pointed at a directory
 #5.2 Now that heatclient can include binary files, discuss making
 stack create/update API calls multipart/form-data so that proper
 mime data can be captured for attached files
 #6.1 Discuss options for where else metadata could be polled from (ie,
 swift)
 #6.2 Discuss whether #6.1 can lead to software-config that can work
 on an OpenStack which doesn't allow admin users or keystone domains
 (ie, rackspace)
 #4.1 thru #4.3 are important and seem straight forward and more about
 finding people to do it. If there are design issues to be figured out,
 maybe we can do it offline via the ML.

 #5.1 and #5.2 are really interesting and map to use cases we have also seen
 internally. Is there a size limit for the binaries? Would this also cover,
 e.g. sending small binaries like a wordpress install tgz instead of doing a
 yum based install? Or would the latter be something to address via #6
 below?

 #6 looks very interesting as well. We also thought about using swift not
 only for metadata but also for sharing installables to instances in cases
 where direct download from the internet, for example, is not possible.
We'll just have to try it to find out were the limits are, but in
general I would assume the following:
* user_data limited to about 16k total, so anything bigger than that
needs to go in the deployment input_values
* practically speaking, a binary could go in a deployment input value or
a swift object resource (which doesn't exist yet) to be passed to the
deployment input value by url
* The default heat.conf max_template_size=524288, so to avoid this limit
binaries should be put into swift outside the scope of heat, and passed
into the template as a parameter URL.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration

[Steve Baker]

On 23/04/14 04:42, Thomas Spatzier wrote:
 Hi all,

 following up on Zane's request from end of last week, I wanted to kick off
 some discussion on the ML around a design summit session proposal titled 
 Next steps for Heat Software Orchestration. I guess there will be things
 that can be sorted out this way and others that can be refined so we can
 have a productive session in Atlanta. I am basically copying the complete
 contents of the session proposal below so we can iterate on various points.
 If it turns out that we need to split off threads, we can do that at a
 later point.

 The session proposal itself is here:
 http://summit.openstack.org/cfp/details/306

 And here are the details:

 With the Icehouse release, Heat includes implementation for software
 orchestration (Kudos to Steve Baker and Jun Jie Nan) which enables clean
 separation of any kind of software configuration from compute instances and
 thus enables a great new set of features. The implementation for software
 orchestration in Icehouse has probably been the major chunk of work to
 achieve a first end-to-end flow for software configuration thru scripts,
 Chef or Puppet, but there is more work to be done to enable Heat for more
 software orchestration use cases beyond the current support.
 Below are a couple of use cases, and more importantly, thoughts on design
 options of how those use cases can be addressed.

 #1 Enable software components for full lifecycle:
 With the current design, software components defined thru SoftwareConfig
 resources allow for only one config (e.g. one script) to be specified.
 Typically, however, a software component has a lifecycle that is hard to
 express in a single script. For example, software must be installed
 (created), there should be support for suspend/resume handling, and it
 should be possible to allow for deletion-logic. This is also in line with
 the general Heat resource lifecycle.
 By means of the optional 'actions' property of SoftwareConfig it is
 possible today to specify at which lifecycle action of a SoftwareDeployment
 resource the single config hook shall be executed at runtime. However, for
 modeling complete handling of a software component, this would require a
 number of separate SoftwareConfig and SoftwareDeployment resources to be
 defined which makes a template more verbose than it would have to be.
 As an optimization, SoftwareConfig could allow for providing several hooks
 to address all default lifecycle operations that would then be triggered
 thru the respective lifecycle actions of a SoftwareDeployment resource.
 Resulting SoftwareConfig definitions could then look like the one outlined
 below. I think this would fit nicely into the overall Heat resource model
 for actions beyond stack-create (suspend, resume, delete). Furthermore,
 this will also enable a closer alignment and straight-forward mapping to
 the TOSCA Simple Profile YAML work done at OASIS and the heat-translator
 StackForge project.

 So in a short, stripped-down version, SoftwareConfigs could look like

 my_sw_config:
   type: OS::Heat::SoftwareConfig
   properties:
 create_config: # the hook for software install
 suspend_config: # hook for suspend action
 resume_config: # hook for resume action
 delete_config: # hook for delete action

 When such a SoftwareConfig gets associated to a server via
 SoftwareDeployment, the SoftwareDeployment resource lifecycle
 implementation could trigger the respective hooks defined in SoftwareConfig
 (if a hook is not defined, a no-op is performed). This way, all config
 related to one piece of software is nicely defined in one place.
OS::Heat::SoftwareConfig itself needs to remain ignorant of heat
lifecycle phases, since it is just a store of config.

Currently there are 2 ways to build configs which are lifecycle aware:
1. have a config/deployment pair, each with different deployment actions
2. have a single config/deployment, and have the config script do
conditional logic
   on the derived input value deploy_action

Option 2. seem reasonable for most cases, but having an option which
maps better to TOSCA would be nice.

Clint's StructuredConfig example would get us most of the way there, but
a dedicated config resource might be easier to use. The deployment
resource could remain agnostic to the contents of this resource though.
The right place to handle this on the deployment side would be in the
orc script 55-heat-config, which could infer whether the config was a
lifecycle config, then invoke the required config based on the value of
deploy_action.

 #2 Enable add-hoc actions on software components:
 Apart from basic resource lifecycle hooks, it would be desirable to allow
 for invocation of add-hoc actions on software. Examples would be the ad-hoc
 creation of DB backups, application of patches, or creation of users for an
 application. Such hooks (implemented as scripts, Chef recipes or Puppet
 facts) could be defined in the same way as basic 

Re: [openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration

[Renat Akhmerov]

On 24 Apr 2014, at 01:43, Ruslan Kamaldinov rkamaldi...@mirantis.com wrote:

 On Tue, Apr 22, 2014 at 8:42 PM, Thomas Spatzier
 thomas.spatz...@de.ibm.com wrote:
 #2 Enable add-hoc actions on software components:

Cool, coincidentally or not but we use term “ad-hoc action” too in Mistral :) 
This is the functionality we implemented a couple of weeks ago. Might be useful 
to sync up on that.

 From the implementation point of view and our previous discussions I figure 
 out
 that Mistral can be a good fit for lifecycle hooks execution. Renat (Mistral
 lead) added a topic [1] for Heat weekly meeting, I hope we can discuss this
 today as part of that topic.

Yes, Ruslan, I’ve been there and we've decided to move the discussion to ML. 
We’re now finalizing our current (which we still conventionally call PoC) 
development phase (preparing necessary materials) so once this is done it’ll be 
much easier to talk about opportunities for integration because everyone will 
be able to find out what exactly Mistral is.

Thanks

Renat Akhmerov
@ Mirantis Inc.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration

[Thomas Spatzier]

Renat Akhmerov rakhme...@mirantis.com wrote on 24/04/2014 08:28:25:

 From: Renat Akhmerov rakhme...@mirantis.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 24/04/2014 08:29
 Subject: Re: [openstack-dev] [Heat] Design summit preparation - Next
 steps for Heat Software Orchestration


 On 24 Apr 2014, at 01:43, Ruslan Kamaldinov rkamaldi...@mirantis.com
wrote:

  On Tue, Apr 22, 2014 at 8:42 PM, Thomas Spatzier
  thomas.spatz...@de.ibm.com wrote:
  #2 Enable add-hoc actions on software components:

 Cool, coincidentally or not but we use term “ad-hoc action” too in
 Mistral :) This is the functionality we implemented a couple of
 weeks ago. Might be useful to sync up on that.

Ok, that sounds good. I was hoping we can move this discussion in a
direction where we can converge several of the recently ongoing
discussions :-) So if this makese sense for everybody and there is time,
let's see what can be covered in that session.

My personal view is that we should discuss what fits as a next step into
Heat's software orchestration (i.e. natural fit without scope bust), and do
it in a way that allows surrounding projects to interface nicely with it.


  From the implementation point of view and our previous discussions
 I figure out
  that Mistral can be a good fit for lifecycle hooks execution. Renat
(Mistral
  lead) added a topic [1] for Heat weekly meeting, I hope we can discuss
this
  today as part of that topic.

 Yes, Ruslan, I’ve been there and we've decided to move the
 discussion to ML. We’re now finalizing our current (which we still
 conventionally call PoC) development phase (preparing necessary
 materials) so once this is done it’ll be much easier to talk about
 opportunities for integration because everyone will be able to find
 out what exactly Mistral is.

 Thanks

 Renat Akhmerov
 @ Mirantis Inc.


 ___
 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

Re: [openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration

[Clint Byrum]

Excerpts from Thomas Spatzier's message of 2014-04-22 09:42:14 -0700:
 
 Hi all,
 
 following up on Zane's request from end of last week, I wanted to kick off
 some discussion on the ML around a design summit session proposal titled 
 Next steps for Heat Software Orchestration. I guess there will be things
 that can be sorted out this way and others that can be refined so we can
 have a productive session in Atlanta. I am basically copying the complete
 contents of the session proposal below so we can iterate on various points.
 If it turns out that we need to split off threads, we can do that at a
 later point.
 
 The session proposal itself is here:
 http://summit.openstack.org/cfp/details/306
 
 And here are the details:
 
 With the Icehouse release, Heat includes implementation for software
 orchestration (Kudos to Steve Baker and Jun Jie Nan) which enables clean
 separation of any kind of software configuration from compute instances and
 thus enables a great new set of features. The implementation for software
 orchestration in Icehouse has probably been the major chunk of work to
 achieve a first end-to-end flow for software configuration thru scripts,
 Chef or Puppet, but there is more work to be done to enable Heat for more
 software orchestration use cases beyond the current support.
 Below are a couple of use cases, and more importantly, thoughts on design
 options of how those use cases can be addressed.
 
 #1 Enable software components for full lifecycle:
 With the current design, software components defined thru SoftwareConfig
 resources allow for only one config (e.g. one script) to be specified.
 Typically, however, a software component has a lifecycle that is hard to
 express in a single script. For example, software must be installed
 (created), there should be support for suspend/resume handling, and it
 should be possible to allow for deletion-logic. This is also in line with
 the general Heat resource lifecycle.
 By means of the optional 'actions' property of SoftwareConfig it is
 possible today to specify at which lifecycle action of a SoftwareDeployment
 resource the single config hook shall be executed at runtime. However, for
 modeling complete handling of a software component, this would require a
 number of separate SoftwareConfig and SoftwareDeployment resources to be
 defined which makes a template more verbose than it would have to be.
 As an optimization, SoftwareConfig could allow for providing several hooks
 to address all default lifecycle operations that would then be triggered
 thru the respective lifecycle actions of a SoftwareDeployment resource.
 Resulting SoftwareConfig definitions could then look like the one outlined
 below. I think this would fit nicely into the overall Heat resource model
 for actions beyond stack-create (suspend, resume, delete). Furthermore,
 this will also enable a closer alignment and straight-forward mapping to
 the TOSCA Simple Profile YAML work done at OASIS and the heat-translator
 StackForge project.
 
 So in a short, stripped-down version, SoftwareConfigs could look like
 
 my_sw_config:
   type: OS::Heat::SoftwareConfig
   properties:
 create_config: # the hook for software install
 suspend_config: # hook for suspend action
 resume_config: # hook for resume action
 delete_config: # hook for delete action


First off, modeling more actions is definitely on the near-term need
list for TripleO. We need to model rebuild and replace as an action too,
so that we can evacuate/migrate work loads off of compute nodes.

I think you can prototype action handling already with StructuredConfig,
which allows you to define your own structure underneath config:.
So you'd just simply do this:

my_sw_config:
  type: OS::Heat::StructuredConfig
  properties:
config:
  create_config: |
#!/bin/bash
execute_stuff
  delete_config: |
#!/bin/bash
execute_delete_stuff

Then your in-instance tools would simply write these as executables and
run them when the action dictates. Suspend and resume aren't currently
exposed, but I think that would be a fairly trivial patch to enable.

Note that IMO we should _not_ encourage users to embed executables in
templates. In addition to muddying the waters between orchestration
and configuration management, it is also a very poor model for long
term source code control. You lose things like renames and per-file
commit history. I think users will be much better served by other tools
bundling software together with a template, and I've always figured that
something like Murano or Solum would do that. So that you'd instead have
a template like this:


my_sw_config:
  type: OS::Heat::StructuredConfig
  properties:
config:
  create_config: {get_file: create_hook.sh}
  delete_config: {get_file: delete_hook.sh}

And if you're image-based, then you'd instead just bundle the image
creation definition and not even need to include instructions on code
injection in 

Re: [openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration

[Thomas Spatzier]

Hi Clint,

thanks for the comments. Those are some really good points. I added some
more thoughts from my side below.

Exceprts from Clint Byrum's message on 24/04/2014 17:53:40:

snip
  So in a short, stripped-down version, SoftwareConfigs could look like
 
  my_sw_config:
type: OS::Heat::SoftwareConfig
properties:
  create_config: # the hook for software install
  suspend_config: # hook for suspend action
  resume_config: # hook for resume action
  delete_config: # hook for delete action
 

 First off, modeling more actions is definitely on the near-term need
 list for TripleO. We need to model rebuild and replace as an action too,
 so that we can evacuate/migrate work loads off of compute nodes.

 I think you can prototype action handling already with StructuredConfig,
 which allows you to define your own structure underneath config:.
 So you'd just simply do this:

 my_sw_config:
   type: OS::Heat::StructuredConfig
   properties:
 config:
   create_config: |
 #!/bin/bash
 execute_stuff
   delete_config: |
 #!/bin/bash
 execute_delete_stuff

Interesting. I had not thought of StructuredConfig in that way yet. So if
the in-instance tool would be implemented in a way that when the
corresponding StructuredDeployment resource is in CREATE_IN_PROGRESS it
executes the create_config, and when it is in DELETE_IN_PROGRESS executes
the delete_config (does the tag-teaming between StructuredDeployment and
the in-instance tool do this today).
I would still slightly prefer a more explicit and top-level definition of
well-defined config hooks will well-defined semantics (i.e. at which
lifecycle step they get executed), though, as opposed to a free-form map.


 Then your in-instance tools would simply write these as executables and
 run them when the action dictates. Suspend and resume aren't currently
 exposed, but I think that would be a fairly trivial patch to enable.

 Note that IMO we should _not_ encourage users to embed executables in
 templates. In addition to muddying the waters between orchestration
 and configuration management, it is also a very poor model for long
 term source code control. You lose things like renames and per-file
 commit history. I think users will be much better served by other tools
 bundling software together with a template, and I've always figured that
 something like Murano or Solum would do that. So that you'd instead have
 a template like this:


 my_sw_config:
   type: OS::Heat::StructuredConfig
   properties:
 config:
   create_config: {get_file: create_hook.sh}
   delete_config: {get_file: delete_hook.sh}

+1 on that! Actually, I posted a wordpress sample yesterday which exactly
does this:

https://review.openstack.org/#/c/89885/


 And if you're image-based, then you'd instead just bundle the image
 creation definition and not even need to include instructions on code
 injection in your template.

  When such a SoftwareConfig gets associated to a server via
  SoftwareDeployment, the SoftwareDeployment resource lifecycle
  implementation could trigger the respective hooks defined in
SoftwareConfig
  (if a hook is not defined, a no-op is performed). This way, all config
  related to one piece of software is nicely defined in one place.
 

 I don't believe nicely defined in one place is the right way to say
 this. I would call it an unmanageable chunk of yaml.

IMHO, an unmanageable chunk of yaml would be if the scripting is inlined.
If the scripts get referenced like mentioned above (I think we both agree
on that), it looks pretty neat to me.


 One point, there is no no-op. Heat's software config has an interface,
 and in-instance tools do the work.  I want to make sure we always stay
 true to that. I don't want Heat to assume anything about what happens
 inside instances. Heat exposes configs, and optionally waits for a
 signal. Nothing more.

Ok, maybe no-op was not the right term, or maybe over-simplifying it. So
what I meant was:
If a SoftwareConfig defined a 'create_config', the SoftwareDeployment would
set its state accordingly to CREATE_IN_PROGRESS and then wait for a signal
from the in-instance tool. The in-instance tool would to the actual work,
signal the SoftwareDeployment which goes to CREATE_COMPLETE and so on. Same
for other operations (delete, suspend, ...).
If a SoftwareConfig did not define a certain config - let's take
'suspend_config' now - the SoftwareDeployment (which can check the content
of the associated SoftwareConfig) can just complete the task directly, i.e.
for SUSPEND directly go to SUSPEND_COMPLETE and avoid the whole round trip
of waiting for a signal from the in-instance tool (which found out it does
not have to do anything).


 
  #2 Enable add-hoc actions on software components:
  Apart from basic resource lifecycle hooks, it would be desirable to
allow
  for invocation of add-hoc actions on software. Examples would be the
ad-hoc
  creation of DB backups, 

Re: [openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration

[Ruslan Kamaldinov]

On Tue, Apr 22, 2014 at 8:42 PM, Thomas Spatzier
thomas.spatz...@de.ibm.com wrote:
 #2 Enable add-hoc actions on software components:
 Apart from basic resource lifecycle hooks, it would be desirable to allow
 for invocation of add-hoc actions on software. Examples would be the ad-hoc
 creation of DB backups, application of patches, or creation of users for an
 application. Such hooks (implemented as scripts, Chef recipes or Puppet
 facts) could be defined in the same way as basic lifecycle hooks. They
 could be triggered by doing property updates on the respective
 SoftwareDeployment resources (just a thought and to be discussed during
 design sessions).
 I think this item could help bridging over to some discussions raised by
 the Murano team recently (my interpretation: being able to trigger actions
 from workflows). It would add a small feature on top of the current
 software orchestration in Heat and keep definitions in one place. And it
 would allow triggering by something or somebody else (e.g. a workflow)
 probably using existing APIs.

Hi Thomas,

This is exactly what we need in Heat for Murano workflows. Also, I believe
that what you described above, perfectly maps on TOSCA, which is also very
good for us :)

From the implementation point of view and our previous discussions I figure out
that Mistral can be a good fit for lifecycle hooks execution. Renat (Mistral
lead) added a topic [1] for Heat weekly meeting, I hope we can discuss this
today as part of that topic.

[1] https://wiki.openstack.org/wiki/Meetings/HeatAgenda


Thanks,
Ruslan

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Heat] Design summit preparation - Next steps for Heat Software Orchestration

[Thomas Spatzier]

Hi all,

following up on Zane's request from end of last week, I wanted to kick off
some discussion on the ML around a design summit session proposal titled 
Next steps for Heat Software Orchestration. I guess there will be things
that can be sorted out this way and others that can be refined so we can
have a productive session in Atlanta. I am basically copying the complete
contents of the session proposal below so we can iterate on various points.
If it turns out that we need to split off threads, we can do that at a
later point.

The session proposal itself is here:
http://summit.openstack.org/cfp/details/306

And here are the details:

With the Icehouse release, Heat includes implementation for software
orchestration (Kudos to Steve Baker and Jun Jie Nan) which enables clean
separation of any kind of software configuration from compute instances and
thus enables a great new set of features. The implementation for software
orchestration in Icehouse has probably been the major chunk of work to
achieve a first end-to-end flow for software configuration thru scripts,
Chef or Puppet, but there is more work to be done to enable Heat for more
software orchestration use cases beyond the current support.
Below are a couple of use cases, and more importantly, thoughts on design
options of how those use cases can be addressed.

#1 Enable software components for full lifecycle:
With the current design, software components defined thru SoftwareConfig
resources allow for only one config (e.g. one script) to be specified.
Typically, however, a software component has a lifecycle that is hard to
express in a single script. For example, software must be installed
(created), there should be support for suspend/resume handling, and it
should be possible to allow for deletion-logic. This is also in line with
the general Heat resource lifecycle.
By means of the optional 'actions' property of SoftwareConfig it is
possible today to specify at which lifecycle action of a SoftwareDeployment
resource the single config hook shall be executed at runtime. However, for
modeling complete handling of a software component, this would require a
number of separate SoftwareConfig and SoftwareDeployment resources to be
defined which makes a template more verbose than it would have to be.
As an optimization, SoftwareConfig could allow for providing several hooks
to address all default lifecycle operations that would then be triggered
thru the respective lifecycle actions of a SoftwareDeployment resource.
Resulting SoftwareConfig definitions could then look like the one outlined
below. I think this would fit nicely into the overall Heat resource model
for actions beyond stack-create (suspend, resume, delete). Furthermore,
this will also enable a closer alignment and straight-forward mapping to
the TOSCA Simple Profile YAML work done at OASIS and the heat-translator
StackForge project.

So in a short, stripped-down version, SoftwareConfigs could look like

my_sw_config:
  type: OS::Heat::SoftwareConfig
  properties:
create_config: # the hook for software install
suspend_config: # hook for suspend action
resume_config: # hook for resume action
delete_config: # hook for delete action

When such a SoftwareConfig gets associated to a server via
SoftwareDeployment, the SoftwareDeployment resource lifecycle
implementation could trigger the respective hooks defined in SoftwareConfig
(if a hook is not defined, a no-op is performed). This way, all config
related to one piece of software is nicely defined in one place.


#2 Enable add-hoc actions on software components:
Apart from basic resource lifecycle hooks, it would be desirable to allow
for invocation of add-hoc actions on software. Examples would be the ad-hoc
creation of DB backups, application of patches, or creation of users for an
application. Such hooks (implemented as scripts, Chef recipes or Puppet
facts) could be defined in the same way as basic lifecycle hooks. They
could be triggered by doing property updates on the respective
SoftwareDeployment resources (just a thought and to be discussed during
design sessions).
I think this item could help bridging over to some discussions raised by
the Murano team recently (my interpretation: being able to trigger actions
from workflows). It would add a small feature on top of the current
software orchestration in Heat and keep definitions in one place. And it
would allow triggering by something or somebody else (e.g. a workflow)
probably using existing APIs.


#3 address known limitations of Heat software orchestration
As of today, there already are a couple of know limitations or points where
we have seen the need for additional discussion and design work. Below is a
collection of such issues.
Maybe some are already being worked on; others need more discussion.

#3.1 software deployment should run just once:
A bug has been raised because with today's implementation it can happen
that SoftwareDeployments get executed multiple