Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

Ok - based on the responses in the thread here, I've re-proposed the global roles specification to keystone's backlog [0]. I'll start working on the implementation and get something in review as soon as possible. I'll plan to move the specification from backlog to Queens once development opens. Th

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On Tue, Jun 6, 2017 at 4:44 PM, Lance Bragstad wrote: > > > On Tue, Jun 6, 2017 at 3:06 PM, Marc Heckmann > wrote: >> >> Hi, >> >> On Tue, 2017-06-06 at 10:09 -0500, Lance Bragstad wrote: >> >> Also, with all the people involved with this thread, I'm curious what the >> best way is to get consens

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On Tue, Jun 6, 2017 at 3:06 PM, Marc Heckmann wrote: > Hi, > > On Tue, 2017-06-06 at 10:09 -0500, Lance Bragstad wrote: > > Also, with all the people involved with this thread, I'm curious what the > best way is to get consensus. If I've tallied the responses properly, we > have 5 in favor of opt

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

Also, with all the people involved with this thread, I'm curious what the best way is to get consensus. If I've tallied the responses properly, we have 5 in favor of option #2 and 1 in favor of option #3. This week is spec freeze for keystone, so I see a slim chance of this getting committed to Pik

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

I replied to John, but directly. I'm sending the responses I sent to him but with the intended audience on the thread. Sorry for not catching that earlier. On Fri, May 26, 2017 at 2:44 AM, John Garbutt wrote: > +1 on not forcing Operators to transition to something new twice, even if > we did g

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

I took a stab at working through the API a bit more and I've capture that information in the spec [0]. Rendered version is available, too [1]. [0] https://review.openstack.org/#/c/464763/ [1] http://docs-draft.openstack.org/63/464763/12/check/gate-keystone-specs-docs-ubuntu-xenial/1dbeb65//doc/bui

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On Fri, May 26, 2017 at 10:21 AM, Sean Dague wrote: > On 05/26/2017 10:44 AM, Lance Bragstad wrote: > > > Interesting - I guess the way I was thinking about it was on a per-token > > basis, since today you can't have a single token represent multiple > > scopes. Would it be unreasonable to have

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On 05/26/2017 10:44 AM, Lance Bragstad wrote: > Interesting - I guess the way I was thinking about it was on a per-token > basis, since today you can't have a single token represent multiple > scopes. Would it be unreasonable to have oslo.context build this > information based on multiple tokens f

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On Fri, May 26, 2017 at 9:31 AM, Sean Dague wrote: > On 05/26/2017 10:05 AM, Lance Bragstad wrote: > > > > > > On Fri, May 26, 2017 at 5:32 AM, Sean Dague > > wrote: > > > > On 05/26/2017 03:44 AM, John Garbutt wrote: > > > +1 on not forcing Operators to transition

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On 05/26/2017 10:05 AM, Lance Bragstad wrote: > > > On Fri, May 26, 2017 at 5:32 AM, Sean Dague > wrote: > > On 05/26/2017 03:44 AM, John Garbutt wrote: > > +1 on not forcing Operators to transition to something new twice, even > > if we did go for option 3. >

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On Fri, May 26, 2017 at 5:32 AM, Sean Dague wrote: > On 05/26/2017 03:44 AM, John Garbutt wrote: > > +1 on not forcing Operators to transition to something new twice, even > > if we did go for option 3. > > > > Do we have an agreed non-distruptive upgrade path mapped out yet? (For > > any of the

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On 05/26/2017 03:44 AM, John Garbutt wrote: > +1 on not forcing Operators to transition to something new twice, even > if we did go for option 3. > > Do we have an agreed non-distruptive upgrade path mapped out yet? (For > any of the options) We spoke about fallback rules you pass but with a > war

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

+1 on not forcing Operators to transition to something new twice, even if we did go for option 3. Do we have an agreed non-distruptive upgrade path mapped out yet? (For any of the options) We spoke about fallback rules you pass but with a warning to give us a smoother transition. I think that's my

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

Hi, thanks for bringing this into discussion in the Operators list. Option 1 and 2 and not complementary but complety different. So, considering "Option 2" and the goal to target it for Queens I would prefer not going into a migration path in Pike and then again in Queens. Belmiro On Fri, May 2

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

On Thu, May 25, 2017 at 2:36 PM, Marc Heckmann wrote: > First of all @Lance, thanks for taking the time to write and summarize > this for us. It's much appreciated. > Absolutely! it helps me think about it, too. > > While I'm not aware of all the nuances, based on my own testing, I feel > that