<div dir="ltr"><div>With OOO we're really be dealing with more of the operations / service cloud and then the user cloud.  Which IMHO is as it should be.  <br><br></div>As far as the APIs, if role based functionality was more easily discoverable it might be easier for users to pull adaptive documentation and create adaptive client help screens.<br>
<br><div>I'd rather target that then separating out APIs as we do with keystone.  But that's just me.<br><br></div><div>-Matt<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 31, 2014 at 12:55 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good points, Jonathan. I've added some comments inline...<br>
<div class=""><br>
On Mon, 2014-03-31 at 10:35 -0400, Jonathan Proulx wrote:<br>
> Some Monday morning pre-coffee thoughts<br>
><br>
> On Sun, Mar 30, 2014 at 10:15 PM, Tom Fifield <<a href="mailto:tom@openstack.org">tom@openstack.org</a>> wrote:<br>
><br>
> > So, my reading is we already have such governance established - but rather<br>
> > than being an individual, it is a committee - the user committee. We'll need<br>
> > to tweak it a bit I guess, but in fact it is already set up such that the TC<br>
> > _must_[1] listen to it ... for at least four hours per year ;)<br>
><br>
> That's definitely a front runner in my mind, cheers to all the hard<br>
> work the existing committee have done around surveys, the expanded<br>
> operations track and everything else.<br>
><br>
> I do think it's a bit confusingly named & that this stems from a<br>
> fundamental flaw in OpenStack community though, that there are two<br>
> parts of the community, "Developers" and "Users" and that "User" means<br>
> someone who deploys and maintains cloud infrastructure.<br>
><br>
> As I see it there's (at least) three major community segments, from<br>
> smallest to largest:<br>
><br>
> * Developer, who write the code<br>
> * Operators/Administrators/(pick your title), who build and maintain<br>
> production clouds<br>
> * Users who actually deploy applications on top of the cloud<br>
><br>
> Obviously many individuals and organizations fall into multiple<br>
> categories and within "Users" as writ above there's a variety of<br>
> constituencies that could be broken out.<br>
<br>
</div>I actually think it is important to segregate the Operators group from<br>
the Administrators group, for one main reason. The activities that each<br>
performs are fundamentally different.<br>
<br>
While it is true that for smaller installations, the individuals doing<br>
operator and admin work are the same people, the work that operators and<br>
admins do is quite different.<br>
<br>
Operators spend time:<br>
<br>
 * deploying and configuring hardware<br>
 * configuring network switches and routing tables<br>
 * installing and configuring OpenStack infrastructure services<br>
 * performing upgrades<br>
 * adding new compute nodes or cells to the deployment<br>
 * running database schema migrations<br>
 * fighting with whatever configuration management tool they use<br>
<br>
Whilst admins spend time:<br>
<br>
 * managing quotas<br>
 * tracking capacity<br>
 * monitoring service availability<br>
 * setting up host aggregates<br>
 * creating new instance types<br>
 * un-doing user's problematic actions<br>
 * enabling or disabling services<br>
<br>
I believe that one of the problems that the OpenStack Compute API has is<br>
that it lumps all users -- end users, admins, and operators -- together.<br>
The same API that allows an end user to launch an instance exposes<br>
resource endpoints for an admin to create flavors and host aggregates<br>
and resource endpoints for an operator to add new compute nodes to the<br>
deployment.<br>
<br>
In other words, the API is unfocused and thus, IMO, less effective at<br>
imparting value to the targeted audience (because the audience is so<br>
well, untargeted).<br>
<br>
I think it would be of value to begin segregating the APIs and the ways<br>
in which we communicate with each group. Users building cloud apps on an<br>
OpenStack API should be treated differently than the operator struggling<br>
to migrate a database schema between major releases of OpenStack.<br>
<br>
Best,<br>
-jay<br>
<div class="HOEnZb"><div class="h5"><br>
> In terms of Governance do the "User Committee" cover all that is not<br>
> dev?  That's really a huge amount of ground to cover and I do think<br>
> they've done a great job of it, especially on the ops side as<br>
> evidenced by this discussion, and I can see they're reaching out more<br>
> to the end users as well or starting to.<br>
><br>
> I'd be interested to hear what those who've been doing the job think<br>
> needs to be done to scale out and cover the whole constituency? More<br>
> member, more volunteer staff, sub-committees, distinct operators and<br>
> end user committees, or perhaps the existing structure is sufficient?<br>
><br>
> > Thoughts? What would you see this group doing?<br>
><br>
> I think the user surveys have been very valuable in seeing how<br>
> OpenStack is used in the wild, continuing that and refining the<br>
> questions so we can identify community priorities is a worthy goal and<br>
> an ongoing task that should definitely be continued.<br>
><br>
> Facilitating the organization of summit tracks & possible inter-summit<br>
> ops gatherings is another I think we have broad agreement on as that<br>
> seems to be happening.<br>
><br>
> Do we want to produce tangible best practices or example architectures<br>
> possibly by inviting in existing configuration management tools?  That<br>
> maybe a reach both in terms of our time availability and the interest<br>
> of the people who are doing that work now to come in under a new<br>
> umbrella.  If that, or something like that were our goal then a PTL<br>
> type structure would probably make more sense.<br>
><br>
> -Jon<br>
><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>