openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

On 07/16/2012 09:55 AM, David Kranz wrote:
> 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.

Again, this was proposed, not decided. Vish and JohnG sent out the
mailing list post to gather feedback.

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

Indeed. /see EC2 APIs.

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

Sure, although in this *particular* case the Cinder project is a
bit-for-bit copy of nova-volumes. In fact, the only thing really of
cause for concern are:

* Providing a migration script for the database tables currently in the
Nova database to the Cinder database
* Ensuring that Keystone's service catalog exposes the volume endpoint
along with the compute endpoint so that volume API calls are routed to
the right endpoint (and there's nothing preventing a simple URL rewrite
redirect for the existing /volumes calls in the Compute API to be routed
directly to the new Volumes endpoint which has the same API

IMHO, it's not at all like the Keystone Light rework that was:

* done in private with little community involvement
* changed the way the API behaved

> 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

No disagreement here at all; though I will point out in the case of
Cinder, there are no API changes.

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

Yep, also agreed here too. And I think John's done a good job of
highlighting this in http://wiki.openstack.org/Cinder

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

Meh... I'm not sure this would actually prove useful. Frankly, we
discussed this issue at the PPB meeting last week and the outcome of it
was: make sure the mailing list is notified with a request for feedback
on migration issues and that you work with the devstack folks to ensure
smooth testing migration.

IMHO, it's the domain of the PTLs of the projects that are affected that
should gather feedback and find consensus. The PPB/technical committee
should advise but I believe this is the purview of the PTLs to make the
final decision on...

> 3. The technical committee should declare that the bar for incompatible
> changes is high, and getting higher.

Again, in the case of Cinder, this isn't really an incompatible change
in the sense that Keystone Light was. Nevertheless, the bar for
incompatible changes SHOULD be high. Whether the technical committee is
responsible for being the final arbiter for this or whether the affected
projects' PTLs should be is a question for debate.

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

Sure, that's a good point, too. I don't think the technical committee
should be involved as anything more than a group to bounce competing
ideas off of -- the PTLs should be the final decisionmakers. But I see
your point and respect it.

Best,
-jay

>  -David
> 
> 
> 
> 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.
>>
>> +1
>>
>>     -Sean
>>
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp