Open Stack

>From: matt <matt at nycresistor.com<mailto:matt at nycresistor.com>>
>Date: Monday, March 31, 2014 9:55 AM
>To: Joe Topjian <joe at topjian.net<mailto:joe at topjian.net>>
>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? ;)

>As I said before,

>why not run it as the OSSG is ran?  an opt in group that can work together to focus on initiatives related to operators needs / wants?

>an OSOG ( OpenStack Operators Group ).  If we want to target development or documentation efforts we can coordinate there.  Also >surveys / possibly setting up something like the UX team for horizon.  A group that cleans up tickets and provides better information for >developers.  Become a resource with a structured involvement.

I agree, in general, in the ad hoc approach.  I'd rather see the output of all this be enhancing the work of the User Committee to articulate the voice of both the "Operators" and the "end users".  I think the point earlier in the thread about the dynamic nature of anyone in "operations"'s work day is very valid from a contribution perspective.  Honestly, I think we could make up more ground right now by focusing on inter-cycle mini summits and the additional Operations focus at the main summits.  The new blueprint review process is also a huge opportunity for "Operators" to contribute in a very meaningful way.


>One of the reasons I think this ad hoc method works best is that there is so much variety in operators.  We don't want the rackspaces, and >HPs for the world dominating the discussion / goals.  We want the little guys to be able to contribute meaningfully.

I totally agree that no one group/company/person should have an overbearing share of influence, but I'd actually argue we have the reverse problem.  Much of the design, and implementation of OpenStack is influenced by the smaller, private cloud, style implementations.  This is very often noticed during and right after deploys with database migrations, new queries, etc, but there are other areas as well.  I would actually like to see these efforts draw out more "Operations" feedback from Rackspace, HP, eBay, CERN, Yahoo, IBM, etc on the pains they are experiencing at scale.  That last thing I want is the "big boys" walking around and saying "this is how everything has to be", but I would like to see the larger implementers showing the community where they fear "this thing won't work and here's why" in a collective voice.

For example, it was clear from feedback at the Operator mini-summit that many folks – both large and small – don't think Ceilometer is going to scale properly.  I know some of the folks offered up to be Core for that product were from larger providers, and were trying to make that very point.  They were rejected, but I think that's a failure of lack of collective voice about the issues being seen at scale coming from the community at all sizes.  More input from those already trying to run services like this at a massive scale would really help these types of discussions.

Perhaps, we actually need a collection of user groups that are bound by size, type of workloads, Enterprise vs Service Provider, etc.  Today, they seem largely based on geography.  While I agree that it's easy to slice things as "big" vs "small", I think there are many other useful slices that we can and should build collective voices around.

>Thoughts?

>-Matt

This is great conversation, though!  I love seeing the "Operator" community pushing for more involvement and getting plugged in to OpenStack, as a whole, in new ways.  If you haven't already, please take a look at the Extra sessions for the Atlanta summit that Tom put together at the start of this discussion - https://etherpad.openstack.org/p/ATL-ops-unconference-RFC.  Back to the main point of this thread,  though, we need to do anything we can to keep the momentum going from the mini-summit, blueprint reviews and these extra ATL sessions.  It feels like trying to change the overall governance will mire that down a bit.  The adhoc approach seems much better – and more flexible – as we iterate on the advancements from the last month or so.

Thanks!
Matt

On Mon, Mar 31, 2014 at 10:43 AM, Joe Topjian <joe at topjian.net<mailto:joe at topjian.net>> wrote:

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

+1

_______________________________________________
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/86cbd9d4/attachment.html>