Open Stack

Hi folks,

Murano matures, and we are getting more and more feedback from our early
adopters. The overall reception is very positive, but at the same time
there are some complaints as well. By now the most significant complaint is
is hard to write workflows for application deployment and maintenance.

Current version of workflow definition markup really have some design
drawbacks which limit its potential adoption. They are caused by the fact
that it was never intended for use for Application Catalog use-cases.

I'll briefly touch these drawbacks first:


   1. Murano's workflow engine is actually a state machine, however the
   workflow markup does not explicitly define the states and transitions.
   2. There is no data isolation within any environment, which causes both
   potential security vulnerabilities and unpredictable workflow behaviours.
   3. There is no easy way to reuse the workflows and their related
   procedures between several applications.
   4. The markup uses JSONPath, which relies on Python's 'eval' function.
   This is insecure and has to be avoided.
   5. 5. The workflow markup is XML-based, which is not a common practice
   in the OpenStack community.

So, it turns out that we have to design and implement a new workflow
definition notation, which will not have any of the issues mentioned above.

At the same time, it should still allow to fully specify the configuration
of any third-party Application, its dependencies with other Applications
and define specific actions which are required for Application deployment,
configuration and life cycle management.

This new notation should allow to do the following:


   -

   List all the required configuration parameters and dependencies for a
   given application
   -

   Validate user input and match it to the defined parameters
   -

   Define specific deployment actions and their execution order
   -

   Define behaviors to handle the events of changes in application's
   environment


Also, it should satisfy the following requirements:


   -

   Minimize the amount of configuration for common application parts, i.e.
   reuse existing configuration parts and add only difference specific to the
   application.
   -

   Allow to use different deployment tools with using the same markup
   constructs. i.e. provide a high-level abstraction on the underlying tools
   (heat, shell, chef, puppet etc)
   -

   For security reasons it should NOT allow to execute arbitrary operations
   - i.e. should allow to run only predefined set of meaningful configuration
   actions.



So, I would suggest to introduce a simple and domain specific notation
which would satisfy these needs:

   -

   Application dependencies and configuration properties are defined
   declaratively, in a way similar to how it is done in Heat templates.
   -

   Each property has special constraints and rules, allowing to validate
   the input and applications relationship within the environment.
   -

   The workflows are defined in imperative way: as a sequence of actions or
   method calls. This may include assigning data variables or calling the
   workflows of other applications.
   -

   All of these may be packaged in a YAML format. The example may look
   something like this [1]


The final version may become a bit more complicated, but as the starting
point this should look fine. I suggest to cover this in more details on our
next IRC meeting on Tuesday.

Any feedback or suggestions are appreciated.


[1] https://etherpad.openstack.org/p/murano-new-dsl-example

--
Regards,
Alexander Tivelkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140214/aff133bc/attachment.html>