Open Stack

Agreed, never said anything was intentional and I understand that, things
just evolve and that¹s how it works.

But instead of further diverging (2 things in oslo) it seems better to
organize and work together instead of against right?

Maybe taskflow can help make that possible, maybe it can't, but if we
don't try how can we know :-)

On 6/20/13 12:43 PM, "Adrian Otto" <adrian.otto at rackspace.com> wrote:

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