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

Thomas Spatzier thomas.spatzier at de.ibm.com
Tue Apr 22 16:42:14 UTC 2014


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 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.

#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.

#3.3 connectivity of instances to heat engine API:
The current metadata and signaling framework has certain dependencies on
connectivity from VMs to the Heat engine API. With some network setups, and
in some customer environments we hit limitations of access from VMs to the
management server. What can be done to enable additional network setups?

#3.4 number of created keystone users for deployments:
It has been pointed out that a large number of keystone users get created
for deployment and concerns have been raised that this could be a problem
for large deployments.

#3.5 support of server groups:
How can a clean model look like where software configs get deployed on
server groups instead of single servers. What is the recommended modeling
and semantics?

#3.6 handling of stack updates for software config:
Stack updates are not cleanly supported with the initial software
orchestration implementation. #1 above could address this issue, but do we
have to do something in addition?

#3.7 stack-abandon and stack-adopt for software-config:
Issues have been found for stack-abandon and stack-adopt with software
configs that need to be addressed. Can this be handled by additional hooks
as lined out under #1?


Regards,
Thomas




More information about the OpenStack-dev mailing list