Open Stack

Hi all

I think some of you were at the Software Config session at summit,
but I'll link the ideas that were discussed:
https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-WIP
https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config

To me the basics of it are:
1. we need an entity/resource to place the configuration (in Heat)
2. we need a resource to install the configuration
    (basically a task in Mistral)


A big issue to me is the conflict between heat's taskflow and the new
external one. What I mean by conflict is that it will become tricky
to manage two parallel taskflow instances in one stack.

This could be solved by:
1: totally using mistral (only use mistral workflow)
2: use a very simple model of just asking mistral to run tasks (no
    workflow) this allows us to use heat's workflow
    but mistral's task runner.

Given that mistral has no real implementation yet, "2" would seem
reasonable to me. (I think Heat developers are open to "1" when
Mistral is more mature.)

How could we use Mistral for config installation?
-------------------------------------------------
1. We have a resource type in Heat that creates tasks in a Mistral
    workflow (manual workflow).
2. Heat pre-configures the server to have a Mistral worker
    installed.
3. the Mistral worker pulls tasks from the workflow and passes them
    to an agent that can run it. (the normal security issues jump up
    here - giving access to the taskflow from a guest).

To do this we need an api that can add tasks to a workflow dynamically.
like this:
- create a simple workflow
- create and run task A [run on server X]
- create and run task B [run on server Y]
- create and run task C [run on server X]

(note: the task is run and completes before the next is added if there
        is a dependancy, if tasks can be run in parallel then we add multiple
        tasks)

The api could be something like:
CRUD <mistral>/workflows/
CRUD <mistral>/workflows/<wf>/tasks


One thing that I am not sure of is how a server(worker) would know if a task
was for it or not.
- perhaps we have a capability property of the task that we can use
   (capablitiy[server] = <server-id>) or actually specify the worker we
   want.

I think this would be a good starting point for Mistral as it is a
very simple but concrete starting point. Also if this is not done in
Mistral we will have to add this in Heat (lets rather have it where
it should be). This will also give us a chance to have confidence
with Mistral before trying to do more complex workflows.

If you (Heat and Mistral developers) are open to this we can discuss
what needs to be done. I am willing to help with implementation.

Thanks
-Angus