Open Stack

Good points, Jonathan. I've added some comments inline...

On Mon, 2014-03-31 at 10:35 -0400, Jonathan Proulx 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.

I actually think it is important to segregate the Operators group from
the Administrators group, for one main reason. The activities that each
performs are fundamentally different.

While it is true that for smaller installations, the individuals doing
operator and admin work are the same people, the work that operators and
admins do is quite different.

Operators spend time:

 * deploying and configuring hardware
 * configuring network switches and routing tables
 * installing and configuring OpenStack infrastructure services
 * performing upgrades
 * adding new compute nodes or cells to the deployment
 * running database schema migrations
 * fighting with whatever configuration management tool they use

Whilst admins spend time:

 * managing quotas
 * tracking capacity
 * monitoring service availability
 * setting up host aggregates
 * creating new instance types
 * un-doing user's problematic actions
 * enabling or disabling services

I believe that one of the problems that the OpenStack Compute API has is
that it lumps all users -- end users, admins, and operators -- together.
The same API that allows an end user to launch an instance exposes
resource endpoints for an admin to create flavors and host aggregates
and resource endpoints for an operator to add new compute nodes to the
deployment.

In other words, the API is unfocused and thus, IMO, less effective at
imparting value to the targeted audience (because the audience is so
well, untargeted).

I think it would be of value to begin segregating the APIs and the ways
in which we communicate with each group. Users building cloud apps on an
OpenStack API should be treated differently than the operator struggling
to migrate a database schema between major releases of OpenStack.

Best,
-jay

> 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