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
On Tue, 2017-06-06 at 17:01 -0400, Erik McCormick wrote:
> On Tue, Jun 6, 2017 at 4:44 PM, Lance Bragstad
> wrote:
> >
> >
> > On Tue, Jun 6, 2017 at 3:06 PM, Marc Heckmann > t.com>
> > wrote:
> > >
> > > Hi,
> > >
> > > On Tue, 2017-06-06 at 10:09 -0500, Lance Bragstad wrote:
> > >
> > > Al
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
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
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 option #2 and 1 in favor of option #3. This week is spec freeze for
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
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
+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
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
I think a option 2 is better.
Best Regards
Chaoyi Huang (joehuang)
From: Lance Bragstad [lbrags...@gmail.com]
Sent: 25 May 2017 3:47
To: OpenStack Development Mailing List (not for usage questions);
openstack-operators@lists.openstack.org
Subject: Re: [openstack-d
See below.
On Thu, 2017-05-25 at 15:49 -0500, Lance Bragstad wrote:
On Thu, May 25, 2017 at 2:36 PM, Marc Heckmann
mailto:marc.heckm...@ubisoft.com>> 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 thin
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
First of all @Lance, thanks for taking the time to write and summarize this for
us. It's much appreciated.
While I'm not aware of all the nuances, based on my own testing, I feel that we
are really close with option 1.
That being said, as you already stated, option 2 is clearly more inline with
On 25/05/17 07:47, Lance Bragstad wrote:
> *Option 2*
>
> Implement global role assignments in keystone.
> /
> /
> /How it works:/
> /
> /
> Role assignments in keystone can be scoped to global context. Users
> can then ask for a globally scoped token
>
> Pros:
> - This approach represents a mo
14 matches
Mail list logo
