Open Stack

Excerpts from Jay Pipes's message of 2016-08-01 10:23:57 -0400:
> On 08/01/2016 08:33 AM, Sean Dague wrote:
> > On 07/29/2016 04:55 PM, Doug Hellmann wrote:
> >> One of the outcomes of the discussion at the leadership training
> >> session earlier this year was the idea that the TC should set some
> >> community-wide goals for accomplishing specific technical tasks to
> >> get the projects synced up and moving in the same direction.
> >>
> >> After several drafts via etherpad and input from other TC and SWG
> >> members, I've prepared the change for the governance repo [1] and
> >> am ready to open this discussion up to the broader community. Please
> >> read through the patch carefully, especially the "goals/index.rst"
> >> document which tries to lay out the expectations for what makes a
> >> good goal for this purpose and for how teams are meant to approach
> >> working on these goals.
> >>
> >> I've also prepared two patches proposing specific goals for Ocata
> >> [2][3].  I've tried to keep these suggested goals for the first
> >> iteration limited to "finish what we've started" type items, so
> >> they are small and straightforward enough to be able to be completed.
> >> That will let us experiment with the process of managing goals this
> >> time around, and set us up for discussions that may need to happen
> >> at the Ocata summit about implementation.
> >>
> >> For future cycles, we can iterate on making the goals "harder", and
> >> collecting suggestions for goals from the community during the forum
> >> discussions that will happen at summits starting in Boston.
> >>
> >> Doug
> >>
> >> [1] https://review.openstack.org/349068 describe a process for managing community-wide goals
> >> [2] https://review.openstack.org/349069 add ocata goal "support python 3.5"
> >> [3] https://review.openstack.org/349070 add ocata goal "switch to oslo libraries"
> >
> > I like the direction this is headed. And I think for the test items, it
> > works pretty well.
> 
> I commented on the reviews, but I disagree with both the direction and 
> the proposed implementation of this.
> 
> In short, I think there's too much stick and not enough carrot. We 
> should create natural incentives for projects to achieve desired 
> alignment in certain areas, but placing mandates on project teams in a 
> diverse community like OpenStack is not useful.
> 
> The consequences of a project team *not* meeting these proposed mandates 
> has yet to be decided (and I made that point on the governance patch 
> review). But let's say that the consequences are that a project is 
> removed from the OpenStack big tent if they fail to complete these 
> "shared objectives".
> 
> What will we do when Swift decides that they have no intention of using 
> oslo.messaging or oslo.config because they can't stand fundamentals 
> about those libraries? Are we going to kick Swift, a founding project of 
> OpenStack, out of the OpenStack big tent?

Yes, your point about the title of that specific proposal is well
made.  I'll be renaming it to "remove obsolete incubated version
of Oslo code" or something similar in the next draft to avoid
confusion.

> Likewise, what if the Manila project team decides they aren't interested 
> in supporting Python 3.5 or a particular greenlet library du jour that 
> has been mandated upon them? Is the only filesystem-as-a-service project 
> going to be booted from the tent?

I hardly think "move off of the EOL-ed version of our language" and
"use a library du jour" are in the same class.  All of the topics
discussed so far are either focused on eliminating technical debt
that project teams have not prioritized consistently or adding
features that, again for consistency, are deemed important by the
overall community (API microversioning falls in that category,
though that's an example and not in any way an approved goal right
now).

> When it comes to the internal implementation of projects, my strong 
> belief is that we should let the project teams be laboratories of 
> innovation and avoid placing mandates on them.
> 
> Let projects choose from a set of vetted options for important libraries 
> or frameworks and allow a project to pave its own road if the project 
> team can justify a reason for that which outweighs any vetted choice 
> (Zaqar's choice to use Falcon fits this kind of thing).

We might have a goal that says projects should drop unapproved
tools. I don't think so far we've considered any that say they
should all use a specific tool that isn't already widely used. I'm
having trouble thinking of an example of that sort of thing that I
would support, but at the same time I'm not prepared to say we would
never do something like that just because of my lack of imagination
this morning. How about if we argue the merits of actual goal
proposals when they're made, instead of posing hypothetical scenarios?

> Finally, instead of these shared OpenStack-wide goals being a different 
> stick-thing for the TC to use, why not just make tags that projects can 
> *choose* to pursue, therefore building in the incentive (as opposed to 
> the punishment) to align with a direction the TC feels is a good one.

Project teams who join the big tent sign up to the rights and
responsibilities that go along with membership. Those responsibilities
include taking some direction from the TC, including regarding work
they may not give the same priority as the broader community. Tags
are a good way to coax teams in a direction, but for some things
we also want teams to prioritize work that benefits the whole
community in a specific time frame, and tags don't give us a mechanism
for that.

> 
> You could have tags like:
> 
>   supports:python-3.5
> 
> or
> 
>   supports:oslo-only
> 
> or things like that. Project teams could then endeavour to achieve said 
> tags if they feel that such a tag absolutely aligns with the team's goals.
> 
> Just my two cents,
> -jay
> 
> > I'm trying to think about how we'd use a model like this to support
> > something a little more abstract such as making upgrades easier. Where
> > we've got a few things that we know get in the way (policy in files,
> > rootwrap rules, paste ini changes), as well as validation, as well as
> > configuration changes. And what it looks like for persistently important
> > items which are going to take more than a cycle to get through.
> >
> > Definitely seems worth giving it a shot on the current set of items, and
> > see how it fleshes out.
> >
> > My only concern at this point is it seems like we're building nested
> > data structures that people are going to want to parse into some kind of
> > visualization in RST, which is a sub optimal parsing format. If we know
> > that people want to parse this in advance, yamling it up might be in
> > order. Because this mostly looks like it would reduce to one of those
> > green/yellow/red checker boards by project and task.
> >
> >     -Sean
> >
>