[openstack-dev] [Mistral] really simple workflow for Heat configuration tasks

Renat Akhmerov rakhmerov at mirantis.com
Tue Nov 12 13:58:36 UTC 2013


On 12 нояб. 2013 г., at 19:04, Thomas Spatzier <thomas.spatzier at de.ibm.com> wrote:

> If yes, is there a way for passing data around - e.g. output produced by
> one software config step is input for another software config step?

Thomas, yes, we’re planning to have a data flow mechanism similar to what you described here. In conjunction with using HA transport (such as RabbitMQ) it will be very useful feature. We’ll share our design on that soon. For now you can take a look at the slides prepared for HK summit at http://www.slideshare.net/RenatAkhmerov/mistral-hong-kong-unconference-track and particularly at slide 14 about data flow. Please also feel free to ask any questions about the project and share your thoughts with us.

> Regards,
> Thomas
> 
> Angus Salkeld <asalkeld at redhat.com> wrote on 12.11.2013 02:15:15:
>> From: Angus Salkeld <asalkeld at redhat.com>
>> To: openstack-dev at lists.openstack.org,
>> Date: 12.11.2013 02:18
>> Subject: [openstack-dev] [Mistral] really simple workflow for Heat
>> configuration tasks
>> 
>> 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
>> 
>> 
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131112/17567dee/attachment.html>


More information about the OpenStack-dev mailing list