Sounds like taskflow could be that program (+1 from me, ha)?
Mistral to me is a nice authenticated REST api + other goodies ontop of
something that reliably executes workflows.
But then what I described is also the majority of what openstack does
(authenticated REST api + other goodies ontop of VM/volume/network/...
workflows).
On 10/22/13 3:28 PM, "Clint Byrum" <cl...@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.htm
>l
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
