Open Stack

>From: matt <matt at nycresistor.com<mailto:matt at nycresistor.com>>
>Date: Monday, March 31, 2014 12:21 PM
>To: Narayan Desai <narayan.desai at gmail.com<mailto:narayan.desai at gmail.com>>
>Cc: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>
>Subject: Re: [Openstack-operators] Atlanta Summit - More Ops? ;)

>Incentives is a very interesting question.

>What sort of incentives exist for devs?

>Acknowledged as Contributor ( ATC ) to OpenStack -- ( resume fodder, free ticket to summit )
>Voting in PTL, TC

>I guess those are the official benefits.  There are the unofficial ones such as being saught after in the job market.

>What sort of incentives do you envision for operators?

>I mean with ATCs it's easy to set a barrier... did you contribute code.  How do you quantify an operators contribution to OpenStack?  When >an operator is distinguished as an active contributor do we provide them with the same abilities as an ATC in dev?  There is no PTL for >operators... no need for voting for TC... though maybe they should?

>It raises interesting questions.  And I think it starts with, do we want to create a role for an ATC outside of development ( I think we already >do for documentation contributors ).  If so, are they an ATC or an ATC*.  Then comes the question of quantifying contribution.

>What are your thoughts?

>

So, I'm still working on some longer responses to previous comments in this thread, but with the move of Blueprints to reviews in Gerritt, I think there is a prefect opportunity to build incentives that are applicable to "Operators".  Between performing reviews or possibly submitting "patches" to the Blueprints themselves, those of us who don't live primarily in the developer world can actively contribute.

>-Matt

Thanks,
Matt VW




On Mon, Mar 31, 2014 at 12:29 PM, Narayan Desai <narayan.desai at gmail.com<mailto:narayan.desai at gmail.com>> wrote:
Hi Matt.

I guess that I slice the problem a little bit differently. while I think that it would be useful to have an advocate on the TC, I think that would probably only fuel the culture mismatch.

I'm a big believer in incentives; I think in this case, all of the project level incentives are structured around development contributions, making unit tests pass, etc. There aren't any incentives explicitly built around reporting operational issues, helping devs get down to root cause, etc. I think that motivation from the top in this regard would help a lot more than having a ops advocate on the TC.
 -nld


On Mon, Mar 31, 2014 at 10:26 AM, matt <matt at nycresistor.com<mailto:matt at nycresistor.com>> wrote:
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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/86060309/attachment.html>