Open Stack

Hi everyone,

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:

   1. workflow definitions should be defined separately and processed by
   stand-alone workflow engines (chef, puppet etc).
   2. 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.
   3. 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)
   4. 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.

Pros of each point:
1 & 2 - keeps Heat simple and gives a possibility to choose the best
workflows and engines among available ones.
3 - adds some kind of all-or-nothing semantics improving the control and
awareness of what's going on inside VMs.
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.

Cons:
- Changes to existing workflows making them aware of Heat existence are
required.

These thoughts might show some gaps in my understanding of how Heat works,
but I would like to share them anyway.

Best regards,
Oleksii Rudenko


On Wed, Oct 9, 2013 at 5:37 PM, Georgy Okrokvertskhov <
gokrokvertskhov at mirantis.com> wrote:

> Hi,
>
> 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.
>
> 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.
>
> 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?
>
> Thanks
> Gosha
>
>
>
>
>
>
>
>
>
> On Wed, Oct 9, 2013 at 7:52 AM, Stan Lagun <slagun at mirantis.com> wrote:
>
>> > Thanks, we're certainly interested in Murano, and are keen to discuss
>> your
>> > roadmap, and where requirements and integration opportunities exist
>> Glad to here it. The same is true from Murano side.
>>
>> 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.
>> 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
>> often requires some other machine already be in some state or some output
>> from a deployment step happened elsewhere.
>>
>> 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.
>> The special use case of Murano is that there is no HOT template author.
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>> 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
>> 1. Process some object (JSON) model describing what
>> services/resources/etc. are need to be deployed
>> 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
>> 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 https://wiki.openstack.org/wiki/Murano/UnifiedAgent on
>> how it is in Murano
>>
>> 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.
>>
>> On Wed, Oct 9, 2013 at 1:24 PM, Steven Hardy <shardy at redhat.com> wrote:
>>
>>> On Wed, Oct 09, 2013 at 12:53:45AM +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.
>>>
>>> Thanks, we're certainly interested in Murano, and are keen to discuss
>>> your
>>> roadmap, and where requirements and integration opportunities exist.
>>>
>>> > 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
>>>
>>> Heat can already do this, you just define either OS::Nova::Server or
>>> AWS::EC2::Instance resource in your template, or possibly a group of
>>> instances via OS::Heat::InstanceGroup if the configuration is the same
>>> for
>>> all VMs
>>>
>>> >    2.
>>> >    Enable secondary IP address from user input on all SQL Windows
>>> instances
>>>
>>> So this again is already possible, via several resource types,
>>> AWS::EC2::NetworkInterface, AWS::EC2::EIP, OS::Neutron::Port etc..
>>>
>>> I suggest using the Neutron resources where possible, if you don't care
>>> about Clouformation portability.
>>>
>>> >    3.
>>> >    Install SQL Server prerequisites on each node
>>>
>>> So Heat is already able to do this, via a couple of methods, for Linux
>>> VMs,
>>> so we just need the in-instance agent support for windows (cloud-init,
>>> optionally combined with agents like cfn-init from heat-cfntools)
>>>
>>> Can you clarify what you're using for in-instance agents currently,
>>> cloudbase-init, and/or some bespoke tools?
>>>
>>> >    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
>>>
>>> I'm not sure what's involved in these steps, but it seems like there are
>>> serialization requirements, which can be handled via WaitConditions.
>>>
>>> One thing I think we do need to look at is ways to enable expression of
>>> serialization requirements via HOT, which don't require use of the
>>> AWS-compatible WaitCondition resources.
>>>
>>> So I think we already have the required functionality, we just need to
>>> build out better native interfaces to it.
>>>
>>> >    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.
>>>
>>> So all of this seems possible right now using WaitConditions, but as
>>> mentioned above we should look at ways to provide a better and more
>>> flexible native interface to similar functionality.
>>>
>>> > 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.
>>>
>>> Yep, we already do coordination of VM deployment and other openstack
>>> resources, by managing implicit and explicit dependencies between those
>>> resources.
>>>
>>> > 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”.
>>>
>>> IMHO there isn't a real need to provide explicit control of the workflow
>>> implied by the resource dependencies for the sort of use-case you
>>> describe.
>>>
>>> What I think is needed is simply a better native interface to
>>> serialization
>>> primitives/resources.
>>>
>>> > 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.
>>>
>>> So as has already been mentioned, Heat defines an internal workflow,
>>> based
>>> on the declarative model defined in the template.
>>>
>>> The model should define dependencies, and Heat should convert those
>>> dependencies into a workflow internally.  IMO if the user also needs to
>>> describe a workflow explicitly in the template, then we've probably
>>> failed
>>> to provide the right template interfaces for describing depenendencies.
>>>
>>> > 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.
>>>
>>> So as others have mentioned, you may also want to look at the TaskFlow
>>> project, as if you really want to define workflow directly, that seems
>>> like
>>> it may be the most appropriate place to do it.
>>>
>>> However I'd very much like to continue the discussion, so we can
>>> understand
>>> what is missing in Heat to support your use-case.
>>>
>>> Can you evaluate the existing Heat functionality, and provide feedback
>>> definining specific issues, so we can define what the functionality gaps
>>> are, and discuss the best way to solve them?
>>>
>>> Thanks!
>>>
>>> Steve
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Sincerely yours
>> Stanislav (Stan) Lagun
>> Senior Developer
>> Mirantis
>>
>> 35b/3, Vorontsovskaya St.
>> Moscow, Russia
>> Skype: stanlagun
>> www.mirantis.com
>> slagun at mirantis.com
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131009/3e1b6d60/attachment.html>