Loading…
This event has ended. View the official site or create your own event → Check it out
This event has ended. Create your own
View analytic
Wednesday, May 14 • 9:50am - 10:30am
Next steps for Heat Software Orchestration

Sign up or log in to save this to your schedule and see who's attending!

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 achieve a first end-to-end flow for software configuration thru scripts, Chef or Puppet, but there is more work to be done to fully enable Heat for more software orchestration use cases beyond the current initial support.
This session aims at discussing such additional use cases, and more importantly, discussing design options of how those cases can be addressed. Below is a collection of ideas/suggestions as well as collection of currently known limitations (or points where there have been discussions around optimization).

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

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

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

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

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


(Session proposed by Thoms Spatzier)


Wednesday May 14, 2014 9:50am - 10:30am
B302

Attendees (115)