Open Stack

On 23/04/15 12:14, Chris Dent wrote:
>
> This might be a bit presumptuous, but why not give it a try...

Not at all, we should *strongly* encourage people to ask questions of 
the candidates.

In fact, I think we should encourage everyone to contribute to the 
discussion, not just the candidates.

> This cycle's TC elections didn't come with a set of prepackaged
> questions and though the self-nomination messages have included some
> very interesting stuff I think it would be useful to get answers
> from the candidates on at least one topical but open-ended
> question. Maybe other people have additional questions they think
> are important but this one is the one that matters to me and also
> captures the role that I wish the TC filled more strongly. Here's
> the preamble:
>
> There are lots of different ways to categorize the various
> stakeholders in the OpenStack community, no list is complete. For
> the sake of this question the people I'm concerned with are the
> developers, end-users and operators of OpenStack: the individuals
> who are actively involved with it on a daily basis. I'm intentionally
> leaving out things like "the downstream".
>
> There are many different ways to define "quality". For the sake of
> this question feel free to use whatever definition you like but take
> it as given that "quality" needs to be improved.
>
> Here's the question:
>
> What can and should the TC at large, and you specifically, do to ensure
> quality improves for the developers, end-users and operators of
> OpenStack as a full system, both as a project being developed and a
> product being used?

As you've identified, that is an extremely broad question and therefore 
it can only be correctly answered with an extremely vague response ;)

The only known way to improve 'quality' for all definitions of 'quality' 
is to make feedback loops shorter.


As for what the Technical Committee can do specifically, in the short 
term I think the most important thing is to make sure that projects have 
the flexibility to respond to their own individual challenges. I think 
we've made some progress in this direction - for example, the 
reorganisation that Neutron has been/is going through would probably 
have been easier had it begun in a big-tent world (it's much easier to 
split repos up than to punt parts of your project to stackforge), and 
that's the kind of change that could potentially allow projects to bring 
in more (but more specialised) core reviewers to reduce average 
time-to-review, thus shortening an important feedback loop. So I think 
the TC needs to be vigilant to make sure it's not making those kinds of 
changes difficult.

And of course we should try to identify ideas that work and introduce 
them to other projects who might benefit from them. But I don't think 
that needs to be the TC's responsibility alone - anyone in the community 
should feel able to do that. When I was a PTL I regarded my most 
important responsibility to be making sure that everyone on the team saw 
themselves as leaders of the project. I think the same applies to the TC.

[Warning: hand-waving ahead]

In the much longer term, I think the biggest improvement in quality 
would come from finding a way to not solve the same problems multiple 
times. I'll give an example: RabbitMQ doesn't scale. I hope that's not a 
controversial example, I think it's generally agreed that it just 
doesn't. Nova has developed Cells to enable itself to scale to very 
large deployments despite that limitation (and others). As a result of 
Cells being developed, every other project that uses RabbitMQ is... 
exactly where it was before. That seems suboptimal.

Right now we have a lot of back-end interfaces where the semantics are 
unclear to OpenStack developers, since they're deployer-defined in many 
cases and no one project really owns them. (Example: even if 
oslo-messaging didn't explicitly rule out durability by acknowledging 
messages *before* they're delivered to the application, there's still no 
way we could rely on it because who knows in what configuration RabbitMQ 
is deployed?) Even worse, the interfaces don't support the invariants we 
care about - like being able to scale to both extremely large and 
extremely small deployments - so that every project must find a way to 
reinvent those itself (or not), on top of the aforementioned unclear 
semantics. I can't say how much impact this has on quality. I would 
guess that it is both substantial and negative.

More co-operation between the various different deployment projects 
might help a little, and in any event would be a Good Thing, and we 
could start encouraging that right away.

Solving the problem entirely will be much harder, to put it mildly. I 
don't know if we'll ever get there (though I don't think it's 
impossible). I do believe that the first step is to have a conversation 
about what our vision is for the OpenStack project as a whole, and I 
think it will be much harder to have that conversation and follow 
through on it if the TC is not committed to it.

cheers,
Zane.