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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
