Hello,

I’m one of the engineer working on Murano project. Recently we started a
discussion about Murano and Heat Software orchestration and I want to
continue this discussion with more technical details.

In our project we do deployment of complex multi-instance Windows services.
Those services usually require specific multi-VM orchestration that is
currently impossible or at least not that easy to achieve with Heat. As you
are currently doing HOT software orchestration design we would like to
participate in HOT Software orchestration design and contribute into it, so
that the Heat could address use-cases which we believe are very common.

For example here is how deployment of a SQL Server cluster goes:

   1.

   Allocate Windows VMs for SQL Server cluster
   2.

   Enable secondary IP address from user input on all SQL Windows instances
   3.

   Install SQL Server prerequisites on each node
   4.

   Choose a master node and install Failover Cluster on it
   5.

   Configure all nodes so that they know which one of them is the master
   6.

   Install SQL Server on all nodes
   7.

   Initialize AlwaysOn on all nodes except for the master
   8.

   Initialize Primary replica
   9.

   Initialize secondary replicas


All of the steps must take place in appropriate order depending on the
state of other nodes. Some steps require an output from previous steps and
all of them require some input parameters. SQL Server requires an Active
Directory service in order to use Failover mechanism and installation of
Active Directory with primary and secondary controllers is a complex
workflow of its own.

That is why it is necessary to have some central coordination service which
would handle deployment workflow and perform specific actions (create VMs
and other OpenStack resources, do something on that VM) on each stage
according to that workflow. We think that Heat is the best place for such
service.

Our idea is to extend HOT DSL by adding  workflow definition capabilities
as an explicit list of resources, components’ states and actions. States
may depend on each other so that you can reach state X only after you’ve
reached states Y and Z that the X depends on. The goal is from initial
state to reach some final state “Deployed”.

There is such state graph for each of our deployment entities (service,
VMs, other things). There is also an action that must be performed on each
state.
For example states graph from example above would look like this:






The goal is to reach Service_Done state which depends on VM1_Done and
VM2_Done states and so on from initial Service_Start state.

We propose to extend HOT DSL with workflow definition capabilities where
you can describe step by step instruction to install service and properly
handle errors on each step.

We already have an experience in implementation of the DSL, workflow
description and processing mechanism for complex deployments and believe
we’ll all benefit by re-using this experience and existing code, having
properly discussed and agreed on abstraction layers and distribution of
responsibilities between OS components. There is an idea of implementing
part of workflow processing mechanism as a part of Convection proposal,
which would allow other OS projects to benefit by using this.

We would like to discuss if such design could become a part of future Heat
version as well as other possible contributions from Murano team.

Regards,
Stan Lagun

-- 

Senior Developer
Mirantis
35b/3, Vorontsovskaya St.
Moscow, Russia
Skype: stanlagun
www.mirantis.com
sla...@mirantis.com
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to