[Openstack-operators] Atlanta Summit - More Ops? ;)

Narayan Desai narayan.desai at gmail.com
Mon Mar 31 14:54:07 UTC 2014

I spend some time about a year ago writing up some thoughts about the user
committee, and the major goals I thought it should have. The start of that
thread is here:
but it continues into the January archives as well:

tl;dr I think that the most important problem for the user committee to
solve is to figure out a dynamic where operators can fully participate in
the project in a deep sense. Openstack has a very developer-centric ethos
and structure, which clashes to a substantial extent with the operator
community. We need to figure out how to productively marry ops culture
(which doesn't focus on writing code, rather on building systems, figuring
out how they break, what features they need, etc) with the development
mission of the project.

I think that Tim's (& co) work on the user summit is a good step in this
direction, but figuring out this culture issue is still the most important
issue to solve.

I'm not lucky enough to have the gift of brevity; several of the mails in
the thread above are quite long, and I think both describe the problems I
see in detail, and also illustrate how the focus on developer culture
doesn't necessarily get the project where it needs to go.

On Mon, Mar 31, 2014 at 9:35 AM, Jonathan Proulx <jon at jonproulx.com> wrote:

> Some Monday morning pre-coffee thoughts
> On Sun, Mar 30, 2014 at 10:15 PM, Tom Fifield <tom at openstack.org> wrote:
> > So, my reading is we already have such governance established - but
> rather
> > than being an individual, it is a committee - the user committee. We'll
> need
> > to tweak it a bit I guess, but in fact it is already set up such that
> the TC
> > _must_[1] listen to it ... for at least four hours per year ;)
> That's definitely a front runner in my mind, cheers to all the hard
> work the existing committee have done around surveys, the expanded
> operations track and everything else.
> I do think it's a bit confusingly named & that this stems from a
> fundamental flaw in OpenStack community though, that there are two
> parts of the community, "Developers" and "Users" and that "User" means
> someone who deploys and maintains cloud infrastructure.
> As I see it there's (at least) three major community segments, from
> smallest to largest:
> * Developer, who write the code
> * Operators/Administrators/(pick your title), who build and maintain
> production clouds
> * Users who actually deploy applications on top of the cloud
> Obviously many individuals and organizations fall into multiple
> categories and within "Users" as writ above there's a variety of
> constituencies that could be broken out.
> In terms of Governance do the "User Committee" cover all that is not
> dev?  That's really a huge amount of ground to cover and I do think
> they've done a great job of it, especially on the ops side as
> evidenced by this discussion, and I can see they're reaching out more
> to the end users as well or starting to.
> I'd be interested to hear what those who've been doing the job think
> needs to be done to scale out and cover the whole constituency? More
> member, more volunteer staff, sub-committees, distinct operators and
> end user committees, or perhaps the existing structure is sufficient?
> > Thoughts? What would you see this group doing?
> I think the user surveys have been very valuable in seeing how
> OpenStack is used in the wild, continuing that and refining the
> questions so we can identify community priorities is a worthy goal and
> an ongoing task that should definitely be continued.
> Facilitating the organization of summit tracks & possible inter-summit
> ops gatherings is another I think we have broad agreement on as that
> seems to be happening.
> Do we want to produce tangible best practices or example architectures
> possibly by inviting in existing configuration management tools?  That
> maybe a reach both in terms of our time availability and the interest
> of the people who are doing that work now to come in under a new
> umbrella.  If that, or something like that were our goal then a PTL
> type structure would probably make more sense.
> -Jon
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140331/acf6dfee/attachment.html>

More information about the OpenStack-operators mailing list