Open Stack

Thanks Adrian for adding that,

Zane, it would be great if you could show up. I have a few questions about
said heat requirements, especially about how the current mechanism
accomplishes those requirements.

IMHO I'd rather not have 2 workflow libraries (aka your scheduler.py) and
taskflow. It would be advantageous I think to focus on one way if we can.
This would be beneficial to all and if we can merge those ideas into
taskflow I'm all for it personally. Since one of the possible
ending-points for taskflow is in oslo, that would seem like a useful merge
of ideas and code instead of a divergent approach.

-Josh

On 6/20/13 9:20 AM, "Adrian Otto" <adrian.otto at rackspace.com> wrote:

>Zane,
>
>Thanks for putting the requirements list together. That's very helpful.
>There is a task-flow meeting today where we can discuss this. I added it
>to the agenda. Please attend if possible:
>
>https://wiki.openstack.org/wiki/Meetings/StateManagement
>
>Thanks,
>
>Adrian
>
>On Jun 20, 2013, at 8:48 AM, Zane Bitter <zbitter at redhat.com>
> wrote:
>
>> After the Heat meeting yesterday I had a discussion with Keith Bray and
>>Jessica Lucci about what sort of features Heat needs from TaskFlow in
>>order to be able to adopt it as a workflow system. In the course of that
>>discussion I volunteered to put together a list of requirements, and
>>here is my first cut at that:
>> 
>> https://wiki.openstack.org/wiki/Heat/TaskSystemRequirements
>> 
>> The key point for me is that workflow is core to what an orchestration
>>system does, and therefore it is essential that we can continue to test
>>integration with it *directly*.
>> 
>> That (combined with a reluctance to take on big external dependencies)
>>makes me sceptical of Celery or similar solutions, but hopefully this
>>information should be a good starting point for Celery experts like
>>Jessica to figure out why I'm wrong ;)
>> 
>> 
>> Incidentally, the coroutine-based task library that we're currently
>>using in Heat is becoming a bit more mature - I've been using it to
>>orchestrate stack updates, which is the most complicated workflow we
>>have. The major remaining pain point is missing the rollback features
>>mentioned on the wiki page. If this proves to be something that is
>>useful across projects, I would be happy to contribute it to Oslo. If
>>anybody is interested in checking it out, the code is here:
>> 
>> https://github.com/openstack/heat/blob/master/heat/engine/scheduler.py
>> 
>> cheers,
>> Zane.
>> 
>> _______________________________________________
>> 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