Open Stack

Hi John,

With reference to http://lists.openstack.org/pipermail/openstack-dev/2014-February/026189.html

Point #3 "unit testing / mock infrastructure is broken" is fixed (https://review.openstack.org/#/c/73984)

Currently we are planning to work on persisting create_volume api using taskflow.
I just want to confirm if any other team/developer is not working on the same task so that efforts will not be duplicated.

Also please let us know if you have any suggestions on the same.

Thanks & Regards,

Abhishek Kekane 

-----Original Message-----
From: Joshua Harlow [mailto:harlowja at yahoo-inc.com] 
Sent: Tuesday, February 04, 2014 6:11 AM
To: OpenStack Development Mailing List (not for usage questions); John Griffith
Cc: Yassine lamgarchal
Subject: Re: [openstack-dev] Cinder + taskflow

Thanks john for the input.

Hopefully we can help focus some of the refactoring on solving the state-management problem very soon.

For the mocking case, is there any active work being done here?

As for the state-management and persistence, I think that the goal of both of these will be reached and it is a good idea to focus around these problems and I am all in to figuring out those solutions, although my guess is that both of these will be long-term no matter what. Refactoring cinder from what it is to what it could/can be will take time (and should take time, to be careful and meticulous) and hopefully we can ensure that focus is retained. Since in the end it benefits everyone :)

Lets reform around that state-management issue (which involved a state-machine concept?). To me the current work/refactoring helps establish tasks objects that can be plugged into this machine (which is part of the problem, without task objects its hard to create a state-machine concept around code that is dispersed). To me that¹s where the current refactoring work helps (in identifying those tasks and adjusting code to be closer to smaller units that do a single task), later when a state-machine concept (or something similar) comes along with will be using these tasks (or variations of) to automate transitions based on given events (the flow concept that exists in taskflow is similar to this already).

The questions I had (or can currently think of) with the state-machine idea (versus just defined flows of tasks) are:

1. What are the events that trigger a state-machine to transition?
  - Typically some type of event causes a machine to transition to a new state (after performing some kind of action). Who initiates that transition.
2. What are the events that will cause this triggering? They are likely related directly to API requests (but may not be).
3. If a state-machine ends up being created, how does it interact with other state-machines that are also running at the same time (does it?)
  - This is a bigger question, and involves how one state-machine could be modifying a resource, while another one could be too (this is where u want only one state-machine to be modifying a resource at a time). This would solve some of the races that are currently existent (while introducing the complexity of distributed locking).
  - It is of my opnion that the same problem in #3 happens when using task and flows that also affect simulatenous resources; so its not a unique problem that is directly connected to flows. Part of this I am hoping the tooz project[1] can help with, since last time I checked they want to help make a nice API around distributed locking backends (among other similar APIs).

[1] https://github.com/stackforge/tooz#tooz

-----Original Message-----
From: John Griffith <john.griffith at solidfire.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Date: Monday, February 3, 2014 at 1:16 PM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Cinder + taskflow

>On Mon, Feb 3, 2014 at 1:53 PM, Joshua Harlow <harlowja at yahoo-inc.com>
>wrote:
>> Hi all,
>>
>> After talking with john g. about taskflow in cinder and seeing more 
>> and more reviews showing up I wanted to start a thread to gather all 
>> our lessons learned and how we can improve a little before continuing 
>> to add too many more refactoring and more reviews (making sure 
>> everyone is understands the larger goal and larger picture of 
>> switching pieces of cinder - piece by piece - to taskflow).
>>
>> Just to catch everyone up.
>>
>> Taskflow started integrating with cinder in havana and there has been 
>>some  continued work around these changes:
>>
>> - https://review.openstack.org/#/c/58724/
>> - https://review.openstack.org/#/c/66283/
>> - https://review.openstack.org/#/c/62671/
>>
>> There has also been a few other pieces of work going in (forgive me 
>> if I missed any...):
>>
>> - https://review.openstack.org/#/c/64469/
>> - https://review.openstack.org/#/c/69329/
>> - https://review.openstack.org/#/c/64026/
>>
>> I think now would be a good time (and seems like a good idea) to 
>>create  the discussion to learn how people are using taskflow, common 
>>patterns  people like, don't like, common refactoring idioms that are 
>>occurring and  most importantly to make sure that we refactor with a 
>>purpose and not just  refactor for refactoring sake (which can be 
>>harmful if not done  correctly). So to get a kind of forward and 
>>unified momentum behind  further adjustments I'd just like to make 
>>sure we are all aligned and  understood on the benefits and yes even 
>>the drawbacks that these  refactorings bring.
>>
>> So here is my little list of benefits:
>>
>> - Objects that do just one thing (a common pattern I am seeing is  
>>determining what the one thing is, without making it to granular that 
>>its  hard to read).
>> - Combining these objects together in a well-defined way (once again 
>>it  has to be carefully done to not create to much granularness).
>> - Ability to test these tasks and flows via mocking (something that 
>>is  harder when its not split up like this).
>> - Features that aren't currently used such as state-persistence (but 
>>will  help cinder become more crash-resistant in the future).
>>   - This one will itself need to be understood before doing [I 
>>started  etherpad @ 
>>https://etherpad.openstack.org/p/cinder-taskflow-persistence
>> for this].
>>
>> List of drawbacks (or potential drawbacks):
>>
>> - Having a understanding of what taskflow is doing adds on a new 
>>layer of  things to know (hopefully docs help in this area, that was 
>>there goal).
>> - Selecting to granular of a task or flow; makes it harder to  
>>follow/understand the task/flow logic.
>> - Focuses on the long-term (not necessarily short-term) 
>>state-management  concerns (can't refactor rome in a day).
>> - Taskflow is being developed at the same time cinder is.
>>
>> I'd be very interested in hearing about others experiences and to 
>>make  sure that we discuss the changes (in a well documented and 
>>agreed on
>> approach) before jumping to much into the 'deep end' with a large 
>>amount  of refactoring (aka, refactoring with a purpose). Let's make 
>>this thread  as useful as we can and try to see how we can unify all 
>>these refactorings  behind a common (and documented & agreed-on) 
>>purpose.
>>
>> A thought, for the reviews above, I think it would be very useful to  
>>etherpad/writeup more in the blueprint what the 'refactoring with a  
>>purpose' is so that its more known to future readers (and for active  
>>reviewers), hopefully this email can start to help clarify that 
>>purpose so  that things proceed as smoothly as possible.
>>
>> -Josh
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>Thanks for putting this together Josh, I just wanted to add a couple of 
>things from my own perspective.
>
>The end-goals of taskflow (specifically persistence and better state
>managment) are the motivating factors for going this route.  We've made 
>a first step with create_volume however we haven't advanced it enough 
>to realize the benefits that we set out to gain by this in the first 
>place.  I still think it's the right direction and IMO we should keep 
>on the path, however there are a number of things that I've noticed 
>that make me lean towards refraining from moving other API calls to 
>taskflow right now.
>
>1. Currently taskflow is pretty much a functional equivalent 
>replacement of what was in the volume manager.  We're not really 
>gaining that much from it (yet).
>
>2. taskflow adds quite a bit of code and indirection that currently 
>IMHO adds a bit of complexity and difficulty in trouble-shooting (I 
>think we're fixing this up and it will continue to get better, I also 
>think this is normal for introduction of new implementations, no 
>criticism intended).
>
>3. Our unit testing / mock infrastructure is broken right now for items 
>that use taskflow.  Particularly cinder.test.test_volume can not be run 
>independently until we fix the taskflow fakes and mock objects.
> I def don't want anything else taskflow related merged until this 
>problem is addressed.
>
>4. We really haven't come up with solutions to the problems we set out 
>to solve in the first place with our first implementation of taskflow 
>(state management and persistence).  Until we have a pattern for 
>solving this I think we should refrain from implementing it in other 
>calls.  A number of people volunteered to work on this at the summit in 
>Hong Kong and have stated that they "have code" however that code or 
>those patches haven't materialized so I think we need to regroup and 
>get this work moving again.
>
>Anyway, I'd like to stabilize things for the create_volume 
>implementation that we have and have a clear well defined pattern that 
>solves problems before we go crazy refactoring every API call to use 
>taskflow and assume all of the potential risk that goes along with it.
>
>Thanks,
>John
>
>_______________________________________________
>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

______________________________________________________________________
Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data.  If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding