Hi Angus,

We will have representatives from our Team . Alex Tivelkov and I will be on
summit. We definitely will participate in design sessions for these hot
topics.

Before the summit we will work in etherpads to add necessary technical
information to have a solid background for discussions. We already checked
BPs and we think we can add more details to them.

As I see, not all BP have etherpad links published on launchpad. Should we
create them and attach to BP's whiteboards?

Do you have any internal design sessions before summit? It would be nice if
we can participate in them too.

Thanks
Gosha






On Tue, Oct 8, 2013 at 2:46 PM, Angus Salkeld <asalk...@redhat.com> wrote:

> On 09/10/13 00:53 +0400, Stan Lagun wrote:
>
>> 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.
>>
>
> I hope you are going to be at summit, as I expect this to an important
> session we have there:
>
> Related summit sessions:
> http://summit.openstack.org/**cfp/details/82<http://summit.openstack.org/cfp/details/82>
> http://summit.openstack.org/**cfp/details/121<http://summit.openstack.org/cfp/details/121>
> http://summit.openstack.org/**cfp/details/78<http://summit.openstack.org/cfp/details/78>
>
> Related blueprints:
> https://blueprints.launchpad.**net/heat/+spec/software-**
> configuration-provider<https://blueprints.launchpad.net/heat/+spec/software-configuration-provider>
> https://blueprints.launchpad.**net/heat/+spec/hot-software-**config-deps<https://blueprints.launchpad.net/heat/+spec/hot-software-config-deps>
> https://blueprints.launchpad.**net/heat/+spec/hot-software-**config<https://blueprints.launchpad.net/heat/+spec/hot-software-config>
> https://blueprints.launchpad.**net/heat/+spec/windows-**instances<https://blueprints.launchpad.net/heat/+spec/windows-instances>
>
> Excuse me if you are well aware of these.
>
> -Angus
>
>
>> 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.
>>
>
> I am really happy that you want to get involved and this sounds like it
> functionally matches quite well to the blueprints at the top.
>
> -Angus
>
>
>
>> 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 <OpenStack-dev@lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.**org <OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>



-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to