<div dir="ltr">> Thanks, we're certainly interested in Murano, and are keen to discuss your<br>> roadmap, and where requirements and integration opportunities exist<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">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"><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:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">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 class="im"><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 class="im">><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 class="im">> 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 class="im">> 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 class="im">> Choose a master node and install Failover Cluster on it<br>
</div>> 5.<br>
<div class="im">> 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 class="im"><br>
> Configure all nodes so that they know which one of them is the master<br>
</div>> 6.<br>
<div class="im">><br>
> Install SQL Server on all nodes<br>
</div>> 7.<br>
<div class="im">><br>
> Initialize AlwaysOn on all nodes except for the master<br>
</div><div class="im">> 8.<br>
><br>
> Initialize Primary replica<br>
> 9.<br>
><br>
</div><div class="im">> 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 class="im"><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 class="im"><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 class="im"><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 class="im">> 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 class="im"><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 class=""><div class="h5"><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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small">Sincerely yours<br>
Stanislav (Stan) Lagun<br>Senior Developer<br>Mirantis</span></span><br><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><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>