Open Stack

On 08/20/2014 02:37 PM, Jay Pipes wrote:
> On 08/20/2014 11:41 AM, Zane Bitter wrote:
>> On 19/08/14 10:37, Jay Pipes wrote:
>>>
>>> By graduating an incubated project into the integrated release, the
>>> Technical Committee is blessing the project as "the OpenStack way" to do
>>> some thing. If there are projects that are developed *in the OpenStack
>>> ecosystem* that are actively being developed to serve the purpose that
>>> an integrated project serves, then I think it is the responsibility of
>>> the Technical Committee to take another look at the integrated project
>>> and answer the following questions definitively:
>>>
>>>   a) Is the Thing that the project addresses something that the
>>> Technical Committee believes the OpenStack ecosystem benefits from by
>>> the TC making a judgement on what is "the "OpenStack way" of addressing
>>> that Thing.
>>>
>>> and IFF the decision of the TC on a) is YES, then:
>>>
>>>   b) Is the Vision and Implementation of the currently integrated
>>> project the one that the Technical Committee wishes to continue to
>>> "bless" as the "the OpenStack way" of addressing the Thing the project
>>> does.
>>
>> I disagree with part (b); projects are not code - projects, like Soylent
>> Green, are people.
> 
> Hey! Don't steal my slide content! :P
> 
> http://bit.ly/navigating-openstack-community (slide 3)
> 
>> So it's not critical that the implementation is the
>> one the TC wants to bless, what's critical is that the right people are
>> involved to get to an implementation that the TC would be comfortable
>> blessing over time. For example, everyone agrees that Ceilometer has
>> room for improvement, but any implication that the Ceilometer is not
>> interested in or driving towards those improvements (because of NIH or
>> whatever) is, as has been pointed out, grossly unfair to the Ceilometer
>> team.
> 
> I certainly have not made such an implication about Ceilometer. What I
> see in the Ceilometer space, though, is that there are clearly a number
> of *active* communities of OpenStack engineers developing code that
> crosses similar problem spaces. I think the TC blessing one of those
> communities before the "market" has had a chance to do a bit more
> natural filtering of quality is a barrier to innovation. I think having
> all of those separate teams able to contribute code to an openstack/
> code namespace and naturally work to resolve differences and merge
> innovation is a better fit for a meritocracy.

I think the other thing that's been discovered in the metering space is
it's not just an engineering problem with the bulk of the hard stuff
already figured out. This problem actually is really hard to get right,
especially when performance and overhead are key.

By blessing one team what we're saying is all the good ideas pool for
tackling this hard problem can only come from that one team. That has a
trade off cost. It means if we believe that Ceilometer is fundamentally
the right architecture but just needs a bit of polish, that's the right
call. It's telling people to just get with the program. But it seems
right now we don't think that's the case. And we includes a bunch of
folks in Ceilometer. As evidenced by a bunch of rearchitecture going on.
Which is fine, it's a hard problem, as evidenced by the fact that there
are a ton of open source projects in the general area.

But by blessing a team, and saddling them with an existing architecture
that no one loves, we're actually making it a lot harder to come up with
a final best in class thing in this slot in the OpenStack universe. The
Ceilometer team has to live within the upgrade constraints, for
instance. They have API stability requirements applied to them. The
entire set of requirements of a project once integrated does impose a
tax on the rate the team can change the project so that stable contracts
are kept up.

Honestly, I don't want this to be about stigma of "kicking something
out", but more about openning up freedom and flexibility to research out
this space, which has shown to be a hard space. I don't want to question
that anyone isn't working hard here, because I absolutely think the
teams doing this are. But I also think that cracking this nut of high
performance metering on a large scale is tough, and only made tougher by
having to go after that solution while also staying within the bounds of
acceptable integrated project evolution.

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140821/6784dcbd/attachment.pgp>