Open Stack

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