Open Stack

On 3/20/19 4:32 PM, melanie witt wrote:
> 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.

Now worries, I'll see if I can get things consolidated tomorrow.

>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>
>>
>
>
>
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190320/d6fb0a96/attachment.sig>