Open Stack

On Tue, 19 Mar 2019 09:10:22 -0500, Lance Bragstad <lbragstad at gmail.com> 
wrote:
> 
> 
> On 3/18/19 4:40 PM, melanie witt wrote:
>> On Sat, 16 Mar 2019 15:17:06 -0400, Colleen Murphy
>> <colleen at gazlene.net> wrote:
>>> I noticed there are some sessions with overlapping topics:
>>>
>>> System scope/RBAC:
>>>
>>> https://www.openstack.org/summit/denver-2019/summit-schedule/events/23712/migrating-nova-apis-to-keystone-scope-types
>>>
>>> https://www.openstack.org/summit/denver-2019/summit-schedule/events/23642/increasing-api-accessibility-with-granular-policy-and-default-roles
>>>
>>>
>>> Unified limits:
>>>
>>> https://www.openstack.org/summit/denver-2019/summit-schedule/events/23715/feedback-gathering-for-unified-limits-proposal
>>>
>>> https://www.openstack.org/summit/denver-2019/summit-schedule/events/23641/unified-limits-update-and-migration
>>>
>>>
>>> Maybe we should combine some of these? What do you think, Melanie and
>>> Lance?
> 
> TL;DR I don't think I have anything novel in the sessions I proposed and
> they could be consolidated.
> 
> I'm not sure how we go about doing that formally, though. I'm happy to
> help drive or setup content for either topic, regardless of who's
> officially moderating the session. Sorry for the duplication!
> 
>>
>> On the system scope one for nova, I was thinking of presenting a
>> step-by-step plan for migrating to using keystone scope types (based
>> on what I learned from discussing with Lance) in order to enable more
>> robust use cases for non-admin users, instead of enhancing our legacy
>> stuff to enable them. I wanted to run the idea by operators and users
>> to get feedback.
> 
> ++
> 
> The session I proposed was driven by the discussion we had around scope
> and authorization a few weeks ago. The functionality has been around in
> keystone and related libraries from some time and we've had forum
> sessions on it in the past. Despite that, there still seems to be plenty
> of confusion around the concepts (developers and operators alike). My
> goal was to get folks who are familiar with the approach in a room with
> operators (at the forum) and developers (at the PTG). I don't think
> there is anything novel about my proposals that we couldn't do in Mel's
> session.
> 
> To be clear, I don't think having nova in the title makes the session
> specific to nova's policy. I think there are several nova policies and
> questions that would be applicable to other services. In other words, I
> imagine the discussion being useful for other developers and operators.
> Walking through a migration with nova would be really useful for
> operators, too. Keystone can share some of the work we did in Stein as
> well, if that helps.

I proposed my sessions after yours without noticing the duplication 
(sorry), so I was thinking, lets roll the sessions I proposed into your 
sessions, and I could cover the nova stuff after your content.

I can create a couple of etherpads, one for each session, containing the 
nova info I wanted to cover, and then you can jump in and add your info 
and then we can adjust all the content to be cohesive.

>>
>> On the unified limits one, the plan is to present a specific proposal
>> from John Garbutt on how to migrate nova to unified limits (with the
>> more complex part being migrating our existing quota limits => unified
>> limits), and get feedback from operators and users.
> 
> Same. I proposed this because bnemec originally suggested it on our
> Forum proposal brainstorming etherpad [0]. The main driver would be to
> get people in a room and pick up where we left off in Denver, especially
> since we missed the mark on a couple things for Stein with respect to
> unified limits.
> 
> [0] https://etherpad.openstack.org/p/DEN-keystone-forum-sessions
>>
>> Both are nova-specific, so if there's 1) enough time in the session
>> and 2) it's OK to have nova-specific migration talk happening, we
>> could combine sessions. It's hard to predict the amount of time needed
>> because that depends on whether folks will have much feedback and
>> discussion, or not. I think I'm OK either way, so let's see what Lance
>> thinks.
>>
>> Cheers,
>> -melanie
>>
>>
>>
>>
> 
>