Hi, I have the same request for Vitrage – we have a forum session on the same hour [1], and would like to attend the auto-scaling SIG session. In general, since the auto-scaling SIG is cross-project, I think it might create conflicts with several other sessions. Thanks, Ifat [1] https://www.openstack.org/summit/denver-2019/summit-schedule/events/23662/us... On Fri, Mar 15, 2019 at 11:46 PM Duc Truong <duc.openstack@gmail.com> wrote:

Hi,

Both the Senlin Project Onboarding and the Auto Scaling SIG Initial Discussion are scheduled for the same time slot at 9am on Tuesday. I’m moderating the Senlin Project Onboarding and would like to attend the Auto Scaling SIG session to represent the Senlin project.

Is it possible to reschedule one of those session to avoid the conflict?

Thanks,

Duc

On 3/18/19 4:40 PM, melanie witt wrote:

On Sat, 16 Mar 2019 15:17:06 -0400, Colleen Murphy <colleen@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/mi...

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23642/in...

Unified limits:

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23715/fe...

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23641/un...

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.

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

On 3/20/19 4:32 PM, melanie witt wrote:

On Tue, 19 Mar 2019 09:10:22 -0500, Lance Bragstad <lbragstad@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@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/mi...

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23642/in...

Unified limits:

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23715/fe...

https://www.openstack.org/summit/denver-2019/summit-schedule/events/23641/un...

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

On Wed, Mar 20, 2019 at 10:40 AM Matt Riedemann <mriedemos@gmail.com> wrote:

On 3/18/2019 4:40 PM, melanie witt wrote:

...

I wanted to run the idea by operators and users to get feedback.

Let me be frank and ask if we (nova) have specific operators and users that are clamoring for these changes and if so, do they plan on not only attending the session but engaging in the development of these pretty massive shifts in how nova works? I know we've been talking about this stuff for a long time, but the demand just doesn't feel like it's there from the operators community, and as a development team we're already spread thin.

I think implementing the new RBAC stuff is pretty important. We've had countless requests on things like a "read-only" user which is not currently achievable without quite a significant overhaul of the existing policies. A read-only user shouldn't be that hard, IMHO. I don't want to derail the topic but I'd be happy to be present at a session like this. I think other operators might also agree. I do however also agree that a lot of saying "I want this" and not pushing code up doesn't give me a lot of speaking power :)

--

Thanks,

Matt

-- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. http://vexxhost.com

On Wed, Mar 20, 2019, at 5:14 PM, Ben Nemec wrote:

On 3/20/19 10:21 AM, Mohammed Naser wrote:

...

On Wed, Mar 20, 2019 at 10:40 AM Matt Riedemann <mriedemos@gmail.com> wrote:

...

On 3/18/2019 4:40 PM, melanie witt wrote:

...

I wanted to run the idea by operators and users to get feedback.

Let me be frank and ask if we (nova) have specific operators and users that are clamoring for these changes and if so, do they plan on not only attending the session but engaging in the development of these pretty massive shifts in how nova works? I know we've been talking about this stuff for a long time, but the demand just doesn't feel like it's there from the operators community, and as a development team we're already spread thin.

I think implementing the new RBAC stuff is pretty important. We've had countless requests on things like a "read-only" user which is not currently achievable without quite a significant overhaul of the existing policies.

Yep, we have multiple customers who have asked for this and up until now the only way we've been able to do it is to rewrite most of the policy rules for every service. That's extremely error-prone and difficult to maintain.

Also, doesn't this work address the longstanding complaint about there being no way to scope an admin account to a single project?

I know at one point we had someone who was doing work upstream to improve this, but I think that kind of tailed off. It seems like there is a compelling business case for us to have someone work on this, but the business and I have disagreed on the definition of "compelling" before, so I make no promises. :-)

Yes, part of this discussion is about addressing that scope-to-not-everything problem, which we want to address with system scope. But that involves redefining service APIs to understand the difference between system and project scope, and re-training operators and users to use the correct scope for the correct context. So it's a useful conversation to have with both developers and operators in the room. Colleen

On 3/20/19 11:29 AM, Lance Bragstad wrote:

On 3/20/19 11:13 AM, Ben Nemec wrote:

...

On 3/20/19 10:21 AM, Mohammed Naser wrote:

...

On Wed, Mar 20, 2019 at 10:40 AM Matt Riedemann <mriedemos@gmail.com> wrote:

...

On 3/18/2019 4:40 PM, melanie witt wrote:

...

I wanted to run the idea by operators and users to get feedback.

Let me be frank and ask if we (nova) have specific operators and users that are clamoring for these changes and if so, do they plan on not only attending the session but engaging in the development of these pretty massive shifts in how nova works? I know we've been talking about this stuff for a long time, but the demand just doesn't feel like it's there from the operators community, and as a development team we're already spread thin.

I think implementing the new RBAC stuff is pretty important.  We've had countless requests on things like a "read-only" user which is not currently achievable without quite a significant overhaul of the existing policies.

I can only speak for keystone, but we're about half way there. We have support for default roles (including `reader`) across many parts of the API and we've fixed scope types in a few places, too. There is still more work to do, but we always figured we would be one of the service to take the plunge on this front. I think that's a good thing though and we can share what speed bumps we've hit, if other services find that useful (this sounds like a PTG topic).

...

Yep, we have multiple customers who have asked for this and up until now the only way we've been able to do it is to rewrite most of the policy rules for every service. That's extremely error-prone and difficult to maintain.

++

...

Also, doesn't this work address the longstanding complaint about there being no way to scope an admin account to a single project?

Correct, it gets us closer to solving that problem.

...

I know at one point we had someone who was doing work upstream to improve this, but I think that kind of tailed off. It seems like there is a compelling business case for us to have someone work on this, but the business and I have disagreed on the definition of "compelling" before, so I make no promises. :-)

I suppose we have a couple of options. We can keep both sessions and make one to go through the migration (for all service). The other could go into how operators adopt what's been done upstream for `reader` roles. Colleen suggested something similar in the keystone meeting this week.

+1. It sounds like there is sufficient discussion material here to fill two sessions. I suppose if the operators nack the feature we might have a problem, but I don't anticipate that for the reasons I mentioned above.

---- On Wed, 20 Mar 2019 10:21:34 -0500 Mohammed Naser <mnaser@vexxhost.com> wrote ----

On Wed, Mar 20, 2019 at 10:40 AM Matt Riedemann <mriedemos@gmail.com> wrote:

...

On 3/18/2019 4:40 PM, melanie witt wrote:

...

I wanted to run the idea by operators and users to get feedback.

Let me be frank and ask if we (nova) have specific operators and users that are clamoring for these changes and if so, do they plan on not only attending the session but engaging in the development of these pretty massive shifts in how nova works? I know we've been talking about this stuff for a long time, but the demand just doesn't feel like it's there from the operators community, and as a development team we're already spread thin.

I have already added the policy migration topic in PTG etherpad[1] L146, with spec link. It is planned with deprecation warning and backward compatible way. I suggested giving the deprecation phase of at least 1 year because these policy changes are huge and might affect many operators as large. But not sure if that enough to ask operator feedback if they say NO(i do not think anyone do not want these improvements).

I think implementing the new RBAC stuff is pretty important. We've had countless requests on things like a "read-only" user which is not currently achievable without quite a significant overhaul of the existing policies.

True, and granular policies are required to implement that 'reader' roles.

A read-only user shouldn't be that hard, IMHO. I don't want to derail the topic but I'd be happy to be present at a session like this. I think other operators might also agree.

I do however also agree that a lot of saying "I want this" and not pushing code up doesn't give me a lot of speaking power :)

This is the target for Train(I could not work on spec in stein), once we land the spec[2], I can start coding on that. [1]https://etherpad.openstack.org/p/nova-ptg-train [2] https://review.openstack.org/#/c/547850/7 -gmann

...

--

Thanks,

Matt

-- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. http://vexxhost.com

---- On Wed, 20 Mar 2019 16:17:45 -0500 melanie witt <melwittt@gmail.com> wrote ----

On Wed, 20 Mar 2019 09:37:54 -0500, Matt Riedemann <mriedemos@gmail.com> wrote:

...

On 3/18/2019 4:40 PM, melanie witt wrote:

...

I wanted to run the idea by operators and users to get feedback.

Let me be frank and ask if we (nova) have specific operators and users that are clamoring for these changes and if so, do they plan on not only attending the session but engaging in the development of these pretty massive shifts in how nova works? I know we've been talking about this stuff for a long time, but the demand just doesn't feel like it's there from the operators community, and as a development team we're already spread thin.

I have customers who have been configuring keystone roles and applying them to non-admin users, configuring their policy.json correctly, and then being unable to access the nova API in the way they wanted [1]. Example: configured non-admin user access to live migration using role:MyRole and it doesn't work, they get 404 Instance Not Found if going across projects. Because of legacy stuff in nova, it only works correctly for role:admin.

After learning more about our history around policy stuff and picking Lance's brain, I found that scope types are a way we could solve the problem. Alternatively, we could fix it legacy-style. But if we go the scope types route, we could use enablement of proper non-admin policy handling as a carrot for getting operators/users to begin using tokens with different scopes to access the API in the way they want.

So, there are operators who want and need this, and based on what I learned from Lance, I think I can organize an effort around pushing this forward in Train. I outlined the steps we need [2]:

1. Add test coverage for existing Nova default policy, to ensure we don't regress. 2. Add Keystone scopes to Nova APIs. For example, server APIs could allow scopes of 'project' and 'system'. 3. Add scope checks to Nova APIs and filter the compute_api.get() accordingly. The ability to filter would need to be added to the compute_api.get() method. If the token scope is 'project', filter the get() by project_id. If the token scope is 'system', do not filter the get(). 4. Remove the hard-coding of 'project_only=True' in the database layer. 5. Educate users about how to request project-scoped vs system-scoped tokens from Keystone [4]. They would need to use a system-scoped token in order to do a server action across projects, whereas a project-scoped token would allow a server action only within a project.

And I will be able to spend time working on it, and my hope is that other people will want to help out too. The first two steps lend themselves especially well to being split up among many contributors and are quite mechanical. I plan to create an etherpad for organizing that work. I think the steps outlined above are not directly related to granular API policy and could be worked on in parallel, IIUC.

+1 for these improvements, these are very useful from the operators perspective. First 3 are matching with what policy updates spec is proposing - https://review.openstack.org/#/c/547850/ I need to update that with review comments and PoC to see how those policies will look like. I am working on those and then we can check if that match with all the requriements. We need to make all policies granular otherwise we would not be able to add the suitable default roles for example system_reader, system_admin etc. During my discussion with John in Denver PTG I think, we thought of doing all these (scope_type, default roles, granular rule) altogether so that there will be a single time policy transition for operator instead of multiple breaks. -gmann

Cheers, -melanie

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1663544 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1663544#c9

James, Project Updates are part of the forum, though they handled separately. I'd expect them to all land on the schedule this week. Thanks, Jimmy

James Slagle <mailto:james.slagle@gmail.com> March 18, 2019 at 6:37 AM

Are the project updates part of the Summit or Forum? I submitted a proposal for the Forum for a TripleO Project Update[1], but it's not yet accepted (unless it's one of the pending proposals in the Working Group room).

I had thought Project Updates were part of the Forum based on https://www.openstack.org/summit/denver-2019/summit-categories/, though I see that the other Project Update sessions are part of their own track in the Summit schedule. Were we supposed to submit these as part of a Summit proposal instead?

[1] https://www.openstack.org/summit/denver-2019/call-for-presentations/preview/...

Jimmy McArthur <mailto:jimmy@openstack.org> March 15, 2019 at 3:30 PM Hello All -

The Forum Selection Committee spent some time last week reviewing submissions. A big thank you to all of the community members that took time out of their busy schedules to help us review. We look forward to delving into many great discussions Denver.

Also happy to announce we were able to allocate space for all Forum submissions. We ended up moving three of the submissions out into the Working Group room, so if you think yours is missing, it's just waiting for its final home.

We worked hard to prevent any conflicts, but please make sure there are no glaring competing time slots. With that in mind.. please have a look at the proposed Forum schedule and let us know if you have any concerns:

https://www.openstack.org/summit/denver-2019/summit-schedule?#track=296

Please keep in mind, we may not be able to change a session time, but we will do our best on an as needed basis.

Cheers, Jimmy

On Mon, Mar 18, 2019 at 6:44 PM Kendall Nelson <kennelson11@gmail.com> wrote:

Hello :)

I email PTLs directly about Project Updates & Project Onboarding (it happened back in February). I didn't ever get a response from Juan though? So if TripleO wants space he should contact me immediately and I can see what space we have left.

If possible, TripleO would like to have a slot for a Project Update. I'm sorry we didn't get this communicated to you when originally requested. We have several folks in the project who are able to give the update at the Summit including myself, Emilien Macchi, and Alex Schultz (current PTL). If you need to designate a speaker, you can use me as I'm in the speaker system. Again, sorry for the late request.

-Kendall (diablo_rojo)

On Mon, Mar 18, 2019 at 8:40 AM Jimmy McArthur <jimmy@openstack.org> wrote:

...

James,

Project Updates are part of the forum, though they handled separately. I'd expect them to all land on the schedule this week.

Thanks, Jimmy

James Slagle March 18, 2019 at 6:37 AM

Are the project updates part of the Summit or Forum? I submitted a proposal for the Forum for a TripleO Project Update[1], but it's not yet accepted (unless it's one of the pending proposals in the Working Group room).

I had thought Project Updates were part of the Forum based on https://www.openstack.org/summit/denver-2019/summit-categories/, though I see that the other Project Update sessions are part of their own track in the Summit schedule. Were we supposed to submit these as part of a Summit proposal instead?

[1] https://www.openstack.org/summit/denver-2019/call-for-presentations/preview/...

Jimmy McArthur March 15, 2019 at 3:30 PM

Hello All -

The Forum Selection Committee spent some time last week reviewing submissions. A big thank you to all of the community members that took time out of their busy schedules to help us review. We look forward to delving into many great discussions Denver.

Also happy to announce we were able to allocate space for all Forum submissions. We ended up moving three of the submissions out into the Working Group room, so if you think yours is missing, it's just waiting for its final home.

We worked hard to prevent any conflicts, but please make sure there are no glaring competing time slots. With that in mind.. please have a look at the proposed Forum schedule and let us know if you have any concerns:

https://www.openstack.org/summit/denver-2019/summit-schedule?#track=296

Please keep in mind, we may not be able to change a session time, but we will do our best on an as needed basis.

Cheers, Jimmy

-- -- James Slagle --