An excellent idea. I believe that if the below message had been sent in
April, the tenor of the discussion would have been much different. I
think a main source of angst around this was that there was no mention
at the Folsom summit of nova-volume being simply removed immediately,
except perhaps inside the session devoted to this subject which many
could not attend.
Stepping up a level, it is hard for a project to move from a
developer-centric (no real customers) way of doing things to one driven by
having real enterprise users/customers. I know this from past
experience. At a certain point, we will have to live with APIs or code
organizations that are sub-optimal because it is just too much of a
burden on real users/operators to change them. Obviously some members of
the community believe this tipping point was the Essex release. It is
also inevitable that development will "slow down" by some measures as
the cost of regressions rises and what George Reese called "technical
debt" has to be repaid.
Going forward, and this may be controversial, I think these kinds of
issues would be best addressed by following these measures:
1. Require each blueprint that involves an API change or significant
operational incompatibility to include a significant justification of
why it is necessary, what the impact would be, and a plan for
deprecation/migration. This justification should assume that the remedy
will have to be applied to a large, running OpenStack system in its
many possible variations, without having to shut down the system
for some unknown amount of time.
2. Require such blueprints to be approved by a technical committee that
includes a significant representation of users/operators. The tradeoffs can
be difficult and need to be discussed.
3. The technical committee should declare that the bar for incompatible
changes is high, and getting higher.
Some might argue that this is too much of a burden and takes authority
away from PTLs, but I think the statement of stability to the
community (and others) would more than compensate for that.
On 7/16/2012 8:04 AM, Sean Dague wrote:
On 07/12/2012 05:40 PM, Vishvananda Ishaya wrote:
Excellent points. Let me make the following proposal:
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.
Mailing list: https://launchpad.net/~openstack
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp