openstack team mailing list archive

[Blake Yeager <blake.yeager@xxxxxxxxx>]

Wow, I have been out for the evening and I feel like I missed out on one of
the most critical threads I have seen on this mailing list in a while.

First of all, I think everyone needs to take a deep breath and remember
that we are all on the same team and part of the same community working to
make OpenStack successful.  We do need to challenge the community to hold
true to it's commitments but we need to do that in a constructive and
positive way.  A healthy meritocracy will encourage debate and not conceit
mediocrity when there are better options to be found.

Reading this thread I think there is a very real criticism around the fact
that not enough emphasis has been placed on forward migration and general
compatibility between OpenStack deployments.  I do not think that the ship
has sailed and I think the Cinder project is a very real example of how we
can reverse that trend and start to take a different approach.  I was in
every session in San Francisco around Cinder and I voted for the separation
of the volume code from Nova.  However, in San Francisco it was decided
that we would maintain nova-volumes for the Folsom release and then
deprecate/remove that code in future releases.  To me this feels like a
very big change to the plan of record.  I understand the desire to tear out
nova-volumes sooner to make development easier but as was pointed out
earlier in this thread it is not practical for people that have active
deployments which currently leverage nova-volumes.

Speaking on behalf of HP which is currently running an implementation which
relies on the current nova-volumes code I do no think we should be forced
to cut over to Cinder in order to upgrade to Folsom.

Vish made a great suggestion which outlined the following 4 steps:

> 1) Leave the code in nova-volume for now.
> 2) Document and test a clear migration path to cinder.
> 3) Take the working example upgrade to the operators list and ask them for
> opinions.
> 4) Decide based on their feedback whether it is acceptable to cut the
nova-
> volume code out for folsom.

I am skeptical that we will be able to cut the nova-volume code out of
Folsom, but I believe that we should let this process run it's course.
 Part of the maturation process has to include suggesting aggressive
changes, listening to the feedback for the community (especially
the operators) and then adjusting the plan based on that feedback.  No one
is saying that we can't change and evolve the code, only that it has to be
done according to a pre-defined schedule and that schedule has to
incorporate feedback from the community.

I am excited to see such passion from the community but we need to make
sure that passion is directed in a constructive manner.

-Blake