[openstack-dev] [Heat] HOT Software configuration proposal

Georgy Okrokvertskhov gokrokvertskhov at mirantis.com
Tue Oct 22 23:42:32 UTC 2013


Hi Clint,

Thank you for the detailed analysis.

>I'm not sure I know what "software orchestration" is, but I will take a
>stab at a succinct definition:

>Coordination of software configuration across multiple hosts.

Having this definition of "software orchestration" what will Heat
software orchestration component BP cover? I just trying to clarify for
myself what is Heat position and view on software orchestration based on
components and Heat view on workflows.

Right now it is not clear where is the separation line between component
and workflow. I think this blurred line introduced a lot of confusion in
this thread as some guys had a workflows based approach in mind and some
had component based view.

Thanks
Georgy



On Tue, Oct 22, 2013 at 3:28 PM, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40 -0700:
> > Hi Thomas,
> >
> > I agree with you on semantics part. At the same time I see a potential
> > question which might appear - if semantics is limited by few states
> visible
> > for Heat engine, then who actually does software orchestration?
> > Will it be reasonable then to have software orchestration as separate
> > subproject for Heat as a part of "Orchestration" OpenStack program? Heat
> > engine will then do dependency tracking and will use components as a
> > reference for software orchestration engine which will perform actual
> > deployment and high level software components coordination.
> >
> > This separated software orchestration engine may address all specific
> > requirements proposed by different teams in this thread without affecting
> > existing Heat engine.
> >
>
> I'm not sure I know what "software orchestration" is, but I will take a
> stab at a succinct definition:
>
> Coordination of software configuration across multiple hosts.
>
> If that is what you mean, then I believe what you actually want is
> workflow. And for that, we have the Mistral project which was recently
> announced [1].
>
> Use that and you will simply need to define your desired workflow and
> feed it into Mistral using a Mistral Heat resource. We can create a
> nice bootstrapping resource for Heat instances that shims the mistral
> workflow execution agent into machines (or lets us use one already there
> via custom images).
>
> I can imagine it working something like this:
>
> resources:
>   mistral_workflow_handle:
>     type: OS::Mistral::WorkflowHandle
>   web_server:
>     type: OS::Nova::Server
>     components:
>       mistral_agent:
>         component_type: mistral
>         params:
>           workflow_: {ref: mistral_workflow_handle}
>   mysql_server:
>     type: OS::Nova::Server
>     components:
>       mistral_agent:
>         component_type: mistral
>         params:
>           workflow_handle: {ref: mistral_workflow_handle}
>   mistral_workflow:
>     type: OS::Mistral::Workflow
>     properties:
>       handle: {ref: mistral_workflow_handle}
>       workflow_reference: mysql_webapp_workflow
>       params:
>         mysql_server: {ref: mysql_server}
>         webserver: {ref: web_server}
>
>
> And then the workflow is just defined outside of the Heat template (ok
> I'm sure somebody will want to embed it, but I prefer stronger
> separation). Something like this gets uploaded as
> "mysql_webapp_workflow":
>
> [ 'step1': 'install_stuff',
>   'step2': 'wait(step1)',
>   'step3': 'allocate_sql_user(server=%mysql_server%)'
>   'step4': 'credentials=wait_and_read(step3)'
>   'step5': 'write_config_file(server=%webserver%)' ]
>
> Or maybe it is declared as a graph, or whatever, but it is not Heat's
> problem how to do workflows, it just feeds the necessary data from
> orchestration into the workflow engine. This also means you can use a
> non OpenStack workflow engine without any problems.
>
> I think after having talked about this, we should have workflow live in
> its own program.. we can always combine them if we want to, but having a
> clear line would mean keeping the interfaces clean.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2013-October/016605.html
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131022/3372f978/attachment.html>


More information about the OpenStack-dev mailing list