[Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom

Sriram Subramanian sriram at sriramhere.com
Mon Jul 16 20:50:56 UTC 2012


Has the user committee selection/ setup process been discussed before? 

Does it matter how big a customer the user represents - big co vs
individual/ enthusiast?

Thanks,
-Sriram


-----Original Message-----
From: openstack-bounces+sriram=sriramhere.com at lists.launchpad.net
[mailto:openstack-bounces+sriram=sriramhere.com at lists.launchpad.net] On
Behalf Of Thierry Carrez
Sent: Monday, July 16, 2012 9:08 AM
To: openstack at lists.launchpad.net
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom

David Kranz wrote:
> 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.

That would be useful. Strengthening a bit the feature proposal process
definitely can't hurt.

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

The Foundation bylaws propose that a "User committee" be set up. I hope that
the User committee can be quickly set up, gets respected people on it and
manages to be representative of all the users/operators of OpenStack. If
done properly, such a committee can get very influential and its public
"recommendations" cannot be easily ignored by the developer side (the
"technical committee").

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

Using the "user committee" setup, you don't really need to take authority
away from the PTL. You increase the influence of the "users"
on technical decisions. You just provide a clear and official mechanism to
represent the interests of "the users" as a whole. Once you have that, if
the PTL or technical committee decides to ignore it, it's a rather strong
decision that better has to be well justified. Its better than having some
arbitrary percentage of "users" in a single committee and then have most
decisions won by the most largely represented party.

If the user committee is an active and respected group, it provides nice
checks and balances against developers living in developer bubbles. Most
issues we have right now with deployer-friendliness are linked to the fact
that "the users" don't have a clear or official voice.

The trick is, of course, to manage to set up such a committee in a way that
represents all the users and deployers. It will be all the more influential
if it is seen as representing all the users, rather than just a loosely-tied
pre-determined subset of large users.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp





More information about the Openstack mailing list