<div dir="ltr">Hi everyone,<div><br></div><div>I've read this thread and I'd like to share some thoughts. In my opinion, workflows (which run on VMs) can be integrated with heat templates as follows:</div><div><ol>
<li>workflow definitions should be defined separately and processed by stand-alone workflow engines (chef, puppet etc). </li><li>the HOT resources should reference workflows which they require, specifying a type of workflow and the way to access a workflow definition. The workflow definition might be provided along with HOT.</li>
<li>Heat should treat the orchestration templates as transactions (i.e. Heat should be able to rollback in two cases: 1) if something goes wrong during processing of an orchestration workflow 2) when a stand-alone workflow engine reports an error during processing of a workflow associated with a resource)<br>
</li><li>Heat should expose an API which enables basic communication between running workflows. Additionally, Heat should provide an API to workflows that allows workflows to specify whether they completed successfully or not. The reference to these APIs should be passed to the workflow engine that is responsible for executing workflows on VMs.</li>
</ol><div>Pros of each point:</div><div>1 & 2 - keeps Heat simple and gives a possibility to choose the best workflows and engines among available ones.</div><div>3 - adds some kind of all-or-nothing semantics improving the control and awareness of what's going on inside VMs.</div>
<div>4 - allows workflow synchronization and communication through Heat API. Provides the error reporting mechanism for workflows. If a workflow does not need this functionality, it can ignore it.</div><div><br></div><div>
Cons:</div><div>- Changes to existing workflows making them aware of Heat existence are required.</div><div><br></div><div>These thoughts might show some gaps in my understanding of how Heat works, but I would like to share them anyway.</div>
</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">Best regards,<div>Oleksii Rudenko</div></div></div>
<br><br><div class="gmail_quote">On Wed, Oct 9, 2013 at 5:37 PM, Georgy Okrokvertskhov <span dir="ltr"><<a href="mailto:gokrokvertskhov@mirantis.com" target="_blank">gokrokvertskhov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>In addition I want to add couple words about flexibility and debugging capabilities. I believe it is quite important for HOT template engine to control all aspects of deployment process execution including software components. Right now I believe Heat lack of control of what is going on the VM side.  In my opinion, HOT template user should be able to define what steps are necessary to deploy complex environment and more important, he should be able to provide a hints to the engine how to deal with errors during deployment. Centralized orchestration sees the whole picture of the environment status while scripts on VM usually have quite limited view. Workflows specification can have on_error actions and centralized orchestration will be capable to make smart decision on how to handle errors during deployment.</div>

<div><br></div><div>I think we need to have a design discussion about the architecture of this centralized orchestration. From the one side, this orchestration should have the whole information about environment state and as Heat has full exposure to the environment it sounds reasonable to have such orchestration as a part of Heat. At the other side, HOT template should be quite simple to be useful, so additional workflows concepts might overload DSL syntax and additional independent orchestration level also sounds quite reasonable and this is what we have now as a Murano project.</div>

<div><br></div><div>It will be nice to have some initial live discussion before the summit as not all developers will be on summit. What do you think about Google hangout session at the end of this week or on the next week?</div>

<div><br></div><div>Thanks</div><div>Gosha</div><div><br></div><div><br></div><div>    </div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">
On Wed, Oct 9, 2013 at 7:52 AM, Stan Lagun <span dir="ltr"><<a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>> Thanks, we're certainly interested in Murano, and are keen to discuss your<br>
> roadmap, and where requirements and integration opportunities exist</div>
<div class="gmail_extra">Glad to here it. The same is true from Murano side.<br>

<br></div><div class="gmail_extra">On sample SQL workflow: that was just an example. I didn't want to bother you with a SQL Server deployment details as it's really not that important. <br></div><div class="gmail_extra">



What I've tried to say is that deployments consists of many steps, the steps vary depending on instance's role, user input and so on. The step on one machine<br></div><div class="gmail_extra">often requires some other machine already be in some state or some output from a deployment step happened elsewhere.<br>



<br></div><div class="gmail_extra">I do understand that it is doable using Heat alone. Actually we do use Heat for some parts of workflow. We do not talk to Nova or Neutron directly.<br></div><div class="gmail_extra">The special use case of Murano is that there is no HOT template author. <br>



Heat is more an administrator's tool who knows how to write HOT templates and wants to deal with low-level configuration aspects. But Murano is quite different. In Murano the developers of workflows/scripts/metadata/etc are not end-users. The user is not doing any sort of programming. He is given a UI dashboard where he can compose desired environment from available building blocks (services). Services may depend on each other and UI guides him how to fulfill all requirements. User also conigures service's (VM's etc.) settings. The number of instances in SQL Server cluster and which one of them is going to be the master are such settings.<br>



</div><div class="gmail_extra"><br>Because we do not know in advance all the instances and resources that would be required for the services that user has chosen and the deployment process is strongly depends on user input we cannot just have some hardcoded HOT template. So what we do is we dynamically generate HOT templates my parameterizing and merging several simpler templates together. Then we use our orchestration engine to send commands to Murano Agents on VMs to perform deployment steps in correct order with all needed input. Probably we could do it without orchestration but then we would need to dynamically generate all that WaitConditions and waiting/signaling scripts etc. - something that would be error-prone and hard to manage at large scales.<br>



<br></div><div class="gmail_extra">So we do believe that some external state orchestration would be very very helpful for complex software services we deal with. Although Murano currently has such engine it is far from perfect. As we thought on cleaner and more explicit approach for state orchestration we came to a vision how to implement it on top of task-orchestration engine like TaskFlow. And then we came up with idea that we can go even farther and implement TaskFlow-as-a-Service service with its own REST API etc that could handle an abstract task orchestration while leaving all deployment-related out of the scope of such service. That opens many additional opportunities for integration that would not be available if we just use TaskFlow library in-process. <br>



<br></div><div class="gmail_extra">But we do believe that it would be better for all of us if it would be Heat and not Murano who provides such orchestration capabilities.<br></div><div class="gmail_extra">And yes, I'm completely agree with you that it should not be a part of HOT templates but something external to it. To my understanding external orchestration needs to be capable of<br>



</div><div class="gmail_extra">1. Process some object (JSON) model describing what services/resources/etc. are need to be deployed<br></div><div class="gmail_extra">2. During orchestration invoke some HOT templates (create nested stacks?) with passing required attributes from that object model as an inputs for the HOT template<br>



</div><div class="gmail_extra">3. Be able to send commands (bash scripts, puppet manifests, chef recipes etc) to VM in correct order with a parameters taken from object model and HOT outputs. See <a href="https://wiki.openstack.org/wiki/Murano/UnifiedAgent" target="_blank">https://wiki.openstack.org/wiki/Murano/UnifiedAgent</a> on how it is in Murano<br>



</div><div class="gmail_extra"><br></div><div class="gmail_extra">We are currently communicating with TaskFlow team on possible contributions to Convection implementation and would be glad to participate in software orchestration part on the Heat side. I'm not pretend that I know all the answers or at least our design is good but in Murano we gained much experience in software orchestration that might be useful for the Heat team and we would definitely like to share our ideas. I also believe that now is the time for that as on summit it may be too late because all the principal decisions are already made. <br>



</div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Wed, Oct 9, 2013 at 1:24 PM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">

<div>On Wed, Oct 09, 2013 at 12:53:45AM +0400, Stan Lagun wrote:<br>
> Hello,<br>
><br>
> I’m one of the engineer working on Murano project. Recently we started a<br>
> discussion about Murano and Heat Software orchestration and I want to<br>
> continue this discussion with more technical details.<br>
<br>
</div>Thanks, we're certainly interested in Murano, and are keen to discuss your<br>
roadmap, and where requirements and integration opportunities exist.<br>
<div><br>
> In our project we do deployment of complex multi-instance Windows services.<br>
> Those services usually require specific multi-VM orchestration that is<br>
> currently impossible or at least not that easy to achieve with Heat. As you<br>
> are currently doing HOT software orchestration design we would like to<br>
> participate in HOT Software orchestration design and contribute into it, so<br>
> that the Heat could address use-cases which we believe are very common.<br>
><br>
> For example here is how deployment of a SQL Server cluster goes:<br>
><br>
</div>>    1.<br>
<div>><br>
>    Allocate Windows VMs for SQL Server cluster<br>
<br>
</div>Heat can already do this, you just define either OS::Nova::Server or<br>
AWS::EC2::Instance resource in your template, or possibly a group of<br>
instances via OS::Heat::InstanceGroup if the configuration is the same for<br>
all VMs<br>
<br>
>    2.<br>
<div>>    Enable secondary IP address from user input on all SQL Windows instances<br>
<br>
</div>So this again is already possible, via several resource types,<br>
AWS::EC2::NetworkInterface, AWS::EC2::EIP, OS::Neutron::Port etc..<br>
<br>
I suggest using the Neutron resources where possible, if you don't care<br>
about Clouformation portability.<br>
<br>
>    3.<br>
<div>>    Install SQL Server prerequisites on each node<br>
<br>
</div>So Heat is already able to do this, via a couple of methods, for Linux VMs,<br>
so we just need the in-instance agent support for windows (cloud-init,<br>
optionally combined with agents like cfn-init from heat-cfntools)<br>
<br>
Can you clarify what you're using for in-instance agents currently,<br>
cloudbase-init, and/or some bespoke tools?<br>
<br>
>    4.<br>
<div>>    Choose a master node and install Failover Cluster on it<br>
</div>>    5.<br>
<div>>    Configure all nodes so that they know which one of them is the master<br>
<br>
</div>I'm not sure what's involved in these steps, but it seems like there are<br>
serialization requirements, which can be handled via WaitConditions.<br>
<br>
One thing I think we do need to look at is ways to enable expression of<br>
serialization requirements via HOT, which don't require use of the<br>
AWS-compatible WaitCondition resources.<br>
<br>
So I think we already have the required functionality, we just need to<br>
build out better native interfaces to it.<br>
<div><br>
>    Configure all nodes so that they know which one of them is the master<br>
</div>>    6.<br>
<div>><br>
>    Install SQL Server on all nodes<br>
</div>>    7.<br>
<div>><br>
>    Initialize AlwaysOn on all nodes except for the master<br>
</div><div>>    8.<br>
><br>
>    Initialize Primary replica<br>
>    9.<br>
><br>
</div><div>>    Initialize secondary replicas<br>
><br>
><br>
> All of the steps must take place in appropriate order depending on the<br>
> state of other nodes. Some steps require an output from previous steps and<br>
> all of them require some input parameters. SQL Server requires an Active<br>
> Directory service in order to use Failover mechanism and installation of<br>
> Active Directory with primary and secondary controllers is a complex<br>
> workflow of its own.<br>
<br>
</div>So all of this seems possible right now using WaitConditions, but as<br>
mentioned above we should look at ways to provide a better and more<br>
flexible native interface to similar functionality.<br>
<div><br>
> That is why it is necessary to have some central coordination service which<br>
> would handle deployment workflow and perform specific actions (create VMs<br>
> and other OpenStack resources, do something on that VM) on each stage<br>
> according to that workflow. We think that Heat is the best place for such<br>
> service.<br>
<br>
</div>Yep, we already do coordination of VM deployment and other openstack<br>
resources, by managing implicit and explicit dependencies between those<br>
resources.<br>
<div><br>
> Our idea is to extend HOT DSL by adding  workflow definition capabilities<br>
> as an explicit list of resources, components’ states and actions. States<br>
> may depend on each other so that you can reach state X only after you’ve<br>
> reached states Y and Z that the X depends on. The goal is from initial<br>
> state to reach some final state “Deployed”.<br>
<br>
</div>IMHO there isn't a real need to provide explicit control of the workflow<br>
implied by the resource dependencies for the sort of use-case you describe.<br>
<br>
What I think is needed is simply a better native interface to serialization<br>
primitives/resources.<br>
<div><br>
> There is such state graph for each of our deployment entities (service,<br>
> VMs, other things). There is also an action that must be performed on each<br>
> state.<br>
> For example states graph from example above would look like this:<br>
><br>
</div><div>> The goal is to reach Service_Done state which depends on VM1_Done and<br>
> VM2_Done states and so on from initial Service_Start state.<br>
><br>
> We propose to extend HOT DSL with workflow definition capabilities where<br>
> you can describe step by step instruction to install service and properly<br>
> handle errors on each step.<br>
<br>
</div>So as has already been mentioned, Heat defines an internal workflow, based<br>
on the declarative model defined in the template.<br>
<br>
The model should define dependencies, and Heat should convert those<br>
dependencies into a workflow internally.  IMO if the user also needs to<br>
describe a workflow explicitly in the template, then we've probably failed<br>
to provide the right template interfaces for describing depenendencies.<br>
<div><br>
> We already have an experience in implementation of the DSL, workflow<br>
> description and processing mechanism for complex deployments and believe<br>
> we’ll all benefit by re-using this experience and existing code, having<br>
> properly discussed and agreed on abstraction layers and distribution of<br>
> responsibilities between OS components. There is an idea of implementing<br>
> part of workflow processing mechanism as a part of Convection proposal,<br>
> which would allow other OS projects to benefit by using this.<br>
><br>
> We would like to discuss if such design could become a part of future Heat<br>
> version as well as other possible contributions from Murano team.<br>
<br>
</div>So as others have mentioned, you may also want to look at the TaskFlow<br>
project, as if you really want to define workflow directly, that seems like<br>
it may be the most appropriate place to do it.<br>
<br>
However I'd very much like to continue the discussion, so we can understand<br>
what is missing in Heat to support your use-case.<br>
<br>
Can you evaluate the existing Heat functionality, and provide feedback<br>
definining specific issues, so we can define what the functionality gaps<br>
are, and discuss the best way to solve them?<br>
<br>
Thanks!<br>
<br>
Steve<br>
<div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><span><font color="#888888">-- <br></font></span><div dir="ltr"><span><font color="#888888"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:'Times New Roman';word-spacing:0px"><span style="font-family:arial;font-size:small">Sincerely yours<br>



Stanislav (Stan) Lagun<br>Senior Developer<br>Mirantis</span></span></font></span><div><br><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:'Times New Roman';word-spacing:0px"><span style="font-family:arial;font-size:small"><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US">35b/3, Vorontsovskaya
St.</span><br>Moscow, Russia<br>Skype: stanlagun<br><a href="http://www.mirantis.com/" target="_blank">www.mirantis.com</a><br><a href="mailto:slagun@mirantis.com" target="_blank">slagun@mirantis.com</a></span></span></div>

</div>


</div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br></div></div><div class="im">Georgy Okrokvertskhov<br>
Technical Program Manager,<br>Cloud and Infrastructure Services,<br>
Mirantis<br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. <a href="tel:%2B1%20650%20963%209828" value="+16509639828" target="_blank">+1 650 963 9828</a><br>
Mob. <a href="tel:%2B1%20650%20996%203284" value="+16509963284" target="_blank">+1 650 996 3284</a><br>
</div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>