Open Stack

Narayan I guess the first fundamental question, as I see it is, do
operators deserve a seat at the TC table?

I can see the value of having that insight available at that level.  But,
the same can be said of users, and security engineering / policy wonks.
And that opens a door to further pollution of what is supposed to be a
fairly agile team intended to be focused on engineering rather than
politics.

As with any large organization finding that happy medium for working with
other departments is difficult.  I don't think that managerially we will
find a total solution.  In fact, I think operators, users, and security
folks should NOT be involved in the TC.  I think that the TC should be
focused inwards on the engineering effort surrounding the development needs
of OpenStack.  If we want to engage at a higher level, then a foundation
seat I think makes more sense.

And, while I think it's important for operators, users, and security wonks
to have buy in at the top of the organization helping to steer over all
direction, I don't think that addresses what most of the operators really
want.  Which is the ability to action change more directly.  The only
analog I've seen that works for accomplishing this, is embeds.  What
openstack needs is full fledged developers who are targeting operator
needs.  We need operators who can code embedded in the standard development
process. The reason we need this, is because any effort to contribute to
OpenStack engineering, is going to require it.  There is just no way around
that.  There's nothing wrong with that either.  This does work.

However, obviously not everyone gets to be able to contribute.  As stated
previously, many of us have day jobs.  We're not given the same levity some
of the community contributor show ponies are.  Someone has to go unclog the
tubes and clean up after dazzling forays into user excess.  That's where I
see an OSOG ( operators group ) coming into play.  The OSOG can set goals
for the contributors or just contribute bugs / blueprints more
effectively.  If operators want a seat at the table, I think the best way
to do that is distill the operators needs in a closed group and then reach
out into existing development methods as a unified front.  At that point,
embedded operators who contribute can take the ball and run with it, and
developers additionally can assist.

That's the model I think makes the most sense for us in the long term.  And
I say this based on experience developing for openstack products and as an
operator on two large openstack clouds.

-Matt


On Mon, Mar 31, 2014 at 10:54 AM, Narayan Desai <narayan.desai at gmail.com>wrote:

> 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:
> http://lists.openstack.org/pipermail/foundation/2012-December/001292.html
> but it continues into the January archives as well:
> http://lists.openstack.org/pipermail/foundation/2013-January/001293.html
>
> 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.
>  -nld
>
>
>
> 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
>>
>
>
> _______________________________________________
> 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/50938b9b/attachment.html>