Open Stack

On Apr 23, 2015, at 11:14 AM, Chris Dent <chdent at redhat.com> wrote:

> This might be a bit presumptuous, but why not give it a try…

Presumptuous? Nah, any candidate should be willing to answer questions.

> 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:
[snip]
> 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?

You really weren't kidding about it being "open-ended", huh? :)

Let me start with developers, since that's the area that's closest to home for me, and especially Nova developers, since that's where my focus is. For devs who are new to contributing to Nova, the biggest frustration is the sheer amount of time it takes to get a patch reviewed. Sure, different reviewers will focus on different things, and will ask you to fix this or that, but you expect that if you've been working in open source for any length of time. What you don't expect is that you work on something, test the hell out of it, and submit it, only to… wait. And wait. And then rebase because it's been sitting so long. And then wait some more.

This isn't the result of reviewers being lazy; it's the result of having too few people available compared to the number of patches in need of review. I would like to see the TC take an active role in helping various teams set up training for new potential core reviewers where there is a shortage to help alleviate this bottleneck.

I'm not sure what you see as the difference between the "end users" and the "operators" of OpenStack, because in my mind they are one and the same. I don't consider the people using, say, public cloud services to be OpenStack end users, because ultimately they just want stuff that works, and if it doesn't, they'll blame the provider, not OpenStack. I see our end users as the people who deploy and run OpenStack clouds.

I'd like to see the core of OpenStack defined more clearly (i.e., Monty's Layer #1 [0]), and everything else able to be added as needed. The current situation is a bit confusing, because there are just so many pieces that one can put together to get something called 'OpenStack'. The Big Tent movement is great, and I'm all for it, but I can see the growth of these 'parts' causing a lot of pain to operators if they don't all work the same way. We know that there is pain now getting things to play together nicely; having dozens more potential pieces would make things much worse for ops. Project that have interfaces that are clearly defined, however, will allow for a much better loose coupling of these parts, and would go a long way to making the work that operators do to integrate things smoother. I think efforts such as the API Working Group is an excellent start in this direction, and I would push for other such standards. They aren't mandatory, but if your project doesn't follow them, you're probably not going to win many friends in the ops community.

[0] http://superuser.openstack.org/articles/openstack-as-layers-but-also-a-big-tent-but-also-a-bunch-of-cats


-- Ed Leafe





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150424/fb1e03c7/attachment.pgp>