Open Stack

Excerpts from Lance Bragstad's message of 2018-05-04 15:16:09 -0500:
> 
> On 05/04/2018 02:55 PM, Harry Rybacki wrote:
> > Greetings All,
> >
> > After a discussion in #openstack-tc[1] earlier today, the Keystone
> > team is adjusting its approach in proposing default roles[2].
> > Subsequently, I have ported the current default roles specification
> > from openstack-specs[3] to keystone-specs[2].
> >
> > The original review has been in a pretty stable state for a few weeks.
> > As such, I propose we allow the new spec an exception to the original
> > Rocky-m1 proposal freeze date.
> 
> I don't have an issue with this, especially since we talked about it heavily at the PTG. We also had people familiar with keystone +1 the openstack-spec prior to keystone's proposal freeze. I'm OK granting an exception here if other keystone contributors don't object.
> 
> >
> > I invite more discussion around default roles, and our proposed
> > approach. The Keystone team has a forum session[4] dedicated to this
> > topic at 1135 on day one of the Vancouver Summit. Everyone should feel
> > welcome and encouraged to attend -- we hope that this work will lead
> > to an OpenStack Community Goal in a not-so-distant release.
> 
> I think scoping this down to be keystone-specific is a smart move. It allows us to focus on building a solid template for other projects to learn from. I was pleasantly surprised to hear people in -tc suggest this as a candidate for a community goal in Stein or T.
> 
> Also, big thanks to jroll, dhellmann, ttx, zaneb, smcginnis, johnsom, and mnaser for taking time to work through this with us.

This is a good opportunity for us to experiment with simplifying a
community process.

We've seen repeatedly that big initiatives like this work best when
the team behind them is committed to the specific initiative.  Rather
than trying to assemble a new team of uncertain membership or
interest to review all "global" specs like this, I like the idea
of the keystone team continuing to drive the work on this change
while seeking input from the rest of the community.

We still need to have consensus about the plan, which we can do via
the normal mailing list threads and review of the spec. And then
when we have one or two projects done as an example, we can review
what else we might need before taking it on as a goal.

Doug