Open Stack

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