openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxxx>]

2012/2/24 Eric Windisch <eric@xxxxxxxxxxxxxxxx>:
> On Friday, February 24, 2012 at 12:01 PM, Ed_Conzel@xxxxxxxx wrote:
>
>> That can work and may be the only choice if there is an extended feature
>> freeze. Although, that may end up creating a service provider-specific
>> fork...which may not be a bad thing.
> It can also be a very, very bad thing. Segmentation of the community
> and an exponentially increased complexity for those of us playing both
> sides of the private/public fence.  I really can't see any advantage
> of forking, even temporarily.

"Forking" has a number of connotations, not all of which necessarily
strictly apply here. We have some fundamental problems we need to
address. To do so effectively while still letting others move forward
towards their goals, the proposal (in its current form) is to let people
work on the things they need to meet their goals in a separate branch
(probably in a separate repository), yet still under the Nova umbrella.
Once we feel we've addressed the aforementioned problems, we can start
merging the features in from these other branches. As I said, I'm
expecting these "experimental" (or whatever designation is appropriate)
branches will frequently be rebased on top of trunk so as to ease a
later merge of the branches.

The fact that these "forks" are still in many ways part of the project
(albeit do not follow the rigour of the OpenStack release cycle), as
well as the fact that they are expected to rebase often, make them fail
to qualify as "forks", at least in the traditional sense.

> I'm opposed to a broad Folsom feature freeze as it would too greatly
> limit progression. However, I also agree that there needs to be a
> better core focus, rather than on sprawl.

I don't believe what Nova needs is features, be they "core" or in the
various drivers. We need stability and dependability.

> I'm not opposed to selective feature inclusion.  On the same token, I
> believe we should either approach the Linux kernel model of "include
> the kitchen sink" or not, and by not, Nova would be the core framework
> upon which various drivers would be provided and could be plumbed.

Would you mind proposing this as a session for the summit? It sounds
like a good chat to have face to face.

One of the things I'd like for us to address in Folsom is actually to
make this easier. Many parts of the nova code base can't easily be split
out, but drivers should be fairly easy to maintain separately. We should
make that simpler. This, like other things I've suggested, is mostly a
job of clarifying contracts between various components.

> If today, for instance, it was announced that Folsom won't include new
> features, then it would be impossible for Coraid, Pillar, or some
> other storage solution provider to offer a driver in Folsom and would
> have wait until G.  Yet, Nexenta just got their driver into Essex.
> Nexenta's 6 month lead just turned into a 12 month lead! Sure, their
> competitor could ship separately, but there *is* a difference between
> inclusion, and now, if only politically and from the perspective of
> marketing.

That is a very good point, and like all good policies, exceptions can be
made. A change that simply adds a new driver (and doesn't really touch
any core parts of Nova at all) would be a very good candidate for an
exception, particularly in the volume subsystem, which, last I looked at
it, seemed quite well behaved.

> If new drivers and new code won't be accepted easily, then these third
> party drivers should be maintained as external plugins. While nice in
> theory, I don't agree with it at this time. These are contributions to
> OpenStack and are core, essential to the success of the community.
> Breaking out drivers, while easier, would fracture the community in
> potentially devastating ways.

That's a valid point of view. However, when we need to weigh it against
the burden of maintaining potentially unmaintainable plugins, it's not
always an easy decision. We'd certainly need to clarify the social
contracts better than we have in the past. So, in case we have to accept
into core a driver for some piece of infrastructure we cannot easily get
access to (and as a team don't really have a vested interest in),
someone needs to be "all over it". We need to make sure those
expectations are clearly communicated.

-- 
Soren Hansen             | http://linux2go.dk/
Senior Software Engineer | http://www.cisco.com/
Ubuntu Developer         | http://www.ubuntu.com/
OpenStack Developer      | http://www.openstack.org/