Open Stack

Joshua,

On Jun 20, 2013, at 12:34 PM, Joshua Harlow <harlowja at yahoo-inc.com>
 wrote:

> 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.

To be clear, Zane did not intentionally diverge. His scheduler.py code pre-dates taskflow. It would be great if we could collaborate and converge though.

Thanks,

Adrian

> 
> -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
>