16:00:20 <lbragstad> #startmeeting keystone
16:00:26 <openstack> Meeting started Tue Aug  7 16:00:20 2018 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:29 <openstack> The meeting name has been set to 'keystone'
16:00:36 <lbragstad> ping ayoung, breton, cmurphy, dstanek, gagehugo, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rodrigods, samueldmq, spilla, aselius, dpar, jdennis, ruan_he, wxy, sonuk
16:00:49 <gagehugo> o/
16:00:50 <kmalloc> o/
16:00:52 <wxy|xiyuan> o/
16:00:59 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
16:01:01 <lbragstad> agenda ^
16:01:16 <cmurphy> o/
16:01:17 <lamt> o/
16:01:49 <lbragstad> short agenda today
16:03:13 <lbragstad> #topic release status
16:03:23 <lbragstad> #link https://releases.openstack.org/rocky/schedule.html
16:03:44 <lbragstad> #info rc1 target is the end of this week
16:04:05 <lbragstad> if there is anything we want to get into RC1, we'll have to do it this week
16:04:41 <lbragstad> i went through bugs last week and I don't have any critical bugs on my radar
16:05:12 <lbragstad> at least not ones that haven't been present in other releases
16:05:38 <ayoung> you mean we have bugs roll over from one release to the next?
16:05:47 <lbragstad> right..
16:05:57 <kmalloc> we have historically had that happen
16:06:02 <lbragstad> correct
16:06:10 <kmalloc> if the bug isn't critical, it can be fixed as needed
16:06:21 <kmalloc> bugs may have existed prior to rocky but only discovered in rocky
16:06:33 <ayoung> or if, say, Nova tags it as wishlist...
16:07:05 <lbragstad> one thing i do is look at all bugs opened during the release and see if anything was opened that might be a release blocker
16:07:41 <lbragstad> so far, i'm not seeing any release blockers
16:07:44 <kmalloc> ++
16:08:12 <lbragstad> if you do see something, please feel free to raise a red flag or ping me
16:08:53 <lbragstad> but everyone here is pretty well-versed in release activities
16:08:58 <ayoung> will we have end to end support for service roles in Queens>
16:09:00 <ayoung> ?
16:09:07 <ayoung> er
16:09:12 <ayoung> Rocky?
16:09:44 <lbragstad> i'm not sure i understand the question
16:10:37 * kmalloc is also confused.
16:10:43 <ayoung> Will we be able to use System roles, including CLI support?
16:10:53 <lbragstad> oh
16:11:00 <ayoung> and Oslo context so we can enforce on them
16:11:23 <knikolla> o/
16:11:28 <kmalloc> well, uhm. possibly in keystone, though i think it's another release before we're really going to be in full swing even in keystone and then outside of it is maybe a community goal?
16:11:36 <knikolla> did we switch meeting channel?
16:11:44 <kmalloc> knikolla: yeah, when we switched times ;)
16:11:49 <lbragstad> we'll be pursing that in stein
16:11:53 <kmalloc> knikolla: like... months ago :)
16:12:02 <kmalloc> there was a conflict in -meeting.
16:12:10 <kmalloc> for the new timeslot
16:12:14 <knikolla> i remember
16:12:38 <kmalloc> ayoung: we have all of the base code/support now in keystone (or most of it)
16:12:39 <knikolla> i had the impression we were on meeting-3, so when i switched irc client i joined that instead :(
16:12:58 <kmalloc> ayoung: and in stein we can be aggressive in making it the way forward.
16:13:15 <ayoung> what is missing?  Without System roles,  mitigation for Bug 968696, falls back to is_admin_project
16:13:15 <openstack> bug 968696 in OpenStack Identity (keystone) ""admin"-ness not properly scoped" [High,In progress] https://launchpad.net/bugs/968696 - Assigned to Adam Young (ayoung)
16:13:30 <lbragstad> #link https://bugs.launchpad.net/keystone/+bugs?field.tag=policy
16:13:44 <lbragstad> ^ that tracks a lot of the work to make keystone's APIs account for different scopes
16:14:04 <kmalloc> most of what is missing is migration paths, documentation, ensuring we make our APIs fully account for scopes
16:14:15 <lbragstad> and it's dependent on the work kmalloc is doing to port APIs to use flask and remove the @protected decorator
16:14:17 <ayoung> but we could write customer policy that bypasses that, so long as we have system scopes, right?
16:14:45 <ayoung> customer policy is OK at this point, I'm concerned with python code support for System role assignments only
16:14:45 <kmalloc> i think flask is ~50% done now,
16:14:59 <kmalloc> and by rocky end i hope to have at least 75% of the work proposed.
16:15:03 <kmalloc> if not all of it
16:15:17 <kmalloc> [for APIs] there will be a couple more cleanups after that (breaking down our middleware)
16:15:21 <ayoung> but we don't need that to enforce on system roles, correct?
16:15:32 <ayoung> just to have it done by default
16:15:53 * kmalloc defers to lbragstad for that. my brain can't context switch to answer that question quickly enough.
16:16:17 <lbragstad> correct - if a deployment wants to keep doing things with the old/broken policy, they can
16:16:32 <lbragstad> for a certain amount of time
16:16:33 <ayoung> No
16:16:41 <ayoung> I want to do things with custom policy
16:16:49 <ayoung> using System role assignements.
16:17:03 <ayoung> Can we do that in Rocky with the existing work?
16:18:03 <lbragstad> ayoung: what are you asking for? the ability to incorporate system scoped tokens into keystone's APIs?
16:18:44 <ayoung> lbragstad, yes, and to enforce on them via oslo-policy in Nova et alles
16:19:33 <lbragstad> there is still work to be done in those other services
16:19:57 <ayoung> lbragstad, assuming we put customer policy in place, it should work though, right?
16:20:41 <lbragstad> what do you mean by customer policy?
16:20:44 <ayoung> oslo-context gets its values from the header that we set in keystonemiddleware, so the other projects should not require code changes
16:20:48 <ayoung> custom
16:21:04 <ayoung> my fingers automatically added the 'er'
16:21:10 <lbragstad> ok
16:21:25 <lbragstad> i wasn't sure if you meant something else
16:21:43 <lbragstad> there might still be service changes
16:21:59 <lbragstad> #link https://bugs.launchpad.net/keystone/+bug/1750660 for example
16:22:00 <openstack> Launchpad bug 1750660 in OpenStack Identity (keystone) "The v3 project API should account for different scopes" [High,Triaged]
16:22:32 <lbragstad> ^ that's a case where the service (keystone specifically) needs to understand the scope of the token being used in order to give the user a response that makes sense within their authorization
16:22:54 <lbragstad> which is more involved than a policy check
16:23:23 <ayoung> OK, to be clear. We had a mitigation path in place using is_admin_project.  I'd like to move people to using System roles.  We need to know if that is going to work.
16:24:00 <lbragstad> so - is_admin_project was basically an override that allowed people to do things at the system level
16:24:06 <ayoung> right
16:24:24 <lbragstad> the migration is that you need to make sure all people that have a role on the project you have acting as the is_admin_project, have that same role on the system
16:24:44 <ayoung> Right.  I want to know if we can start doing that based on Rocky
16:25:05 <ayoung> or if there is no reason to start using system roles, and to build on top of is_admin_project today
16:25:10 <lbragstad> i'm inclinced to say no, because i imagine there are bugs like https://bugs.launchpad.net/keystone/+bug/1750660 still in the system
16:25:11 <openstack> Launchpad bug 1750660 in OpenStack Identity (keystone) "The v3 project API should account for different scopes" [High,Triaged]
16:25:38 <lbragstad> the plumbing is there and ready to use, we just need to start using it in the business logic of the services
16:26:01 <ayoung> ++
16:26:24 <lbragstad> I'd like to make stein the release where we drive that home for keystone
16:26:40 <lbragstad> (e.g. i give a system scoped tokne to keystone and list all projects and i get all projects in the deployment)
16:28:35 <lbragstad> anything else on release specific stuff?
16:28:40 <ayoung> lbragstad, ok.
16:29:00 <lbragstad> ayoung: happy to continue working through this in office hours, if you'd like
16:29:43 <lbragstad> # PTG preparation
16:29:51 <lbragstad> #topic PTG preparation
16:29:59 <ayoung> It is a major feature.  Just want to know if it really is in a specific release.  I think we need a plan for making it official in Stein
16:30:21 <lbragstad> ayoung: i'm all for that, too
16:30:26 <lbragstad> hrybacki: was interested in it
16:30:38 <lbragstad> though i assume there is a correlation there ;)
16:31:09 <lbragstad> #topic PTG preparation
16:31:17 <lbragstad> hmm - o well
16:31:20 <lbragstad> anyway
16:31:22 <lbragstad> #link https://etherpad.openstack.org/p/keystone-stein-ptg
16:31:36 <lbragstad> be sure to continue adding things to that etherpad if you'd like to spend time on it at the PTG
16:31:43 <lbragstad> we have Monday as a cross-project day
16:31:59 <lbragstad> in addition to thursday and friday as keystone-specific days
16:32:26 <lbragstad> i'm going to formalize the context into an actual schedule during the last week of august
16:32:34 <lbragstad> content*
16:33:05 <lbragstad> anyone have anything specific for the PTG?
16:33:48 <lbragstad> #topic open discussion
16:34:01 <ayoung> Self service
16:34:18 <lbragstad> just FYI - i'm going to be hanging out with wxy-xiyuan next week in Xi'an
16:34:36 <ayoung> I'd like to have a long term focus on self service from the Keystone team, and a definitinon of what that means
16:34:40 <lbragstad> so i expect most communication to by async
16:35:27 <ayoung> knikolla, has some code for requesting new resources in Keystone.  Its in a stand alone server.  I think it points out some of the pain we've inflicted on Operators that we need  separate servcie like that
16:35:44 <ayoung> we need a series of statements like:
16:35:56 <knikolla> with adjutant being accepted as an official project, we should piggyback on that
16:35:59 <ayoung> as a member, I should be able to see the other members of a project
16:36:17 <ayoung> as a user with no role assignments, I should be able to request a role on a project
16:36:33 <ayoung> as a project administrator, I should be able to offer a role assignment to  a user
16:36:41 <lbragstad> yeah - that goes hand in hand with some of the system scope stuff
16:36:52 <ayoung> some of that was in the Virtuyal Org discussion with David Chadwick a few years back...shiver
16:36:57 <knikolla> ayoung: i would rewrite that to "as a project admin i would like to be able to add users to my project"
16:37:02 <lbragstad> it's a good first step in helping enable a much better self-service story IMO
16:37:09 <kmalloc> knikolla: as long as adjutant doesn't lean on keystone for auth.
16:37:16 <ayoung> knikolla, assuming I know their user ID.  But what if I just have Federation data?
16:37:20 <kmalloc> knikolla: if it does, we run into the same issues we have with barbican
16:37:38 <knikolla> kmalloc: what do you mean?
16:37:46 <kmalloc> knikolla: barbican needs keystone auth to work
16:37:55 <knikolla> users who have no auth at all?
16:37:57 <kmalloc> therefore keystone cannot use barbican as a datastore
16:38:06 <knikolla> oh, i see
16:38:17 <knikolla> well, adjutant would be a layer on top of keystone
16:38:19 <kmalloc> if adjutant needs keystone to auth things, keystone cannot use it as a backing project
16:38:21 <ayoung> knikolla, can you set up a demo of your project at some point?
16:38:24 <knikolla> keystone itself wouldn't need it
16:38:34 <kmalloc> just to be clear adjutant needs to be over keystone
16:38:43 <cmurphy> yes
16:38:45 <kmalloc> wanted to be sure we didn't cross that conversaion again :)
16:39:03 <knikolla> ayoung: i think i have one running. i used it to register spring's class.
16:39:12 <ayoung> other self service operations are "as a project manager, I should be able to enumerate all resources scoped to my project" andthat one is a hard one
16:39:12 * kmalloc still would like to see keystone able to use vault for secret storage.
16:39:23 <kmalloc> [and possibly fernet keys]
16:39:26 <kmalloc> but that is a different thing.
16:40:08 <cmurphy> i think we'll eventually be able to lean on castellan for that
16:40:11 <knikolla> for context, by "my project" ayoung is referring to https://github.com/CCI-MOC/ksproj
16:40:17 <ayoung> as a user, I should be able to list my roles on a project
16:40:30 <ayoung> as a user, I should be able to identify what role I need to access a remote API
16:40:32 <ayoung> and so on
16:40:48 <knikolla> though i would like to merge its featureset to adjutant
16:41:07 <ayoung> A user can get their list of roles via a token issue, but not via role list.  Its a little wonky
16:42:21 <lbragstad> we essentially have to teach those apis how to deal with scope
16:42:43 <ayoung> knikolla, "adjutant" is what?
16:42:50 <lbragstad> it's a new openstack project
16:43:06 <knikolla> ayoung: self-service admin workflows
16:43:16 <cmurphy> https://adjutant.readthedocs.io/en/latest/
16:43:48 <lbragstad> #link https://github.com/openstack/adjutant
16:44:05 <knikolla> right now i think you can add users to a project you are project-admin on, list, remove, etc.
16:44:05 <lbragstad> adriant has been working on it for quite some time
16:44:22 <lbragstad> they use it at catalyst?
16:44:46 <ayoung> please tell me they used Flask.
16:44:55 <knikolla> ayoung: django rest framework
16:45:11 <ayoung> Ah well, close enough
16:45:44 <kmalloc> i have zero issues with django, flask, or <insert non-custom-rolled-webob wsgi thing here>
16:45:45 <kmalloc> :)
16:46:01 <kmalloc> heck, i'd take a nodejs application if it uses a good framework
16:46:43 <ayoung> No you wouldn't
16:47:31 <ayoung> OK, so I'll work with the Adjutant stuff for self service.
16:47:40 <knikolla> ayoung: i already has that
16:47:46 <knikolla> the only blocker is federated users
16:47:57 <knikolla> the mechanism for inviting users to project is very different in ksproj
16:48:15 <ayoung> knikolla, OK,  we can discuss off meeting
16:48:19 <knikolla> ++
16:48:37 <knikolla> we should also talk to adriant, though timezone-wise that will be a bit hard
16:48:45 <ayoung> ++
16:50:01 <lbragstad> anything else for open discussion?
16:50:14 <kmalloc> lbragstad: i have topics for PTG, to add to the etherpad
16:50:29 <lbragstad> awesome, it's all yours
16:52:21 <kmalloc> i'll get that done and book PTG ticket etc.
16:52:36 <lbragstad> PTG ticket prices are rising soon if they haven't already
16:52:44 <lbragstad> just a heads up
16:53:12 <cmurphy> some people internally have been approaching me about a standalone keystone, where'd we leave off on that? anyone else seeing a pressing use case for that?
16:53:23 * kmalloc was almost certain he booked the PTG ticket but i guess i didn't
16:53:37 <lbragstad> cmurphy: as in strictly an identity provider?
16:53:45 <kmalloc> cmurphy: as in a full fledged idp?
16:53:45 <cmurphy> lbragstad: ya
16:53:56 <cmurphy> kmalloc: also yes
16:54:00 <kmalloc> i think we agreed it was somerhing we'd happily put on the roadmap and work on
16:54:06 <lbragstad> afaik - i think that fell to the floor
16:54:13 <kmalloc> but hasn't moved forward
16:54:21 <kmalloc> so, yes we'll totally accept those changes.
16:54:24 <lbragstad> something we all wanted to entertain but no movement on it
16:54:27 <kmalloc> but no one is working on it
16:54:29 <kmalloc> yet
16:54:55 <cmurphy> what they want is to use it to integrate with non-openstack projects
16:55:29 <kmalloc> oh thats right, PTG price is WAY higher this time. i need to expense it right away.
16:55:39 <kmalloc> that is why i didn't do it yet.
16:55:57 <knikolla> i think it started at 199 when i got it
16:56:01 <kmalloc> cmurphy: right. and that lines up with the proxy-idp bit we were talkign to craig about
16:56:03 <lbragstad> cmurphy: do you know what's preventing them from doing that today?
16:56:10 <kmalloc> knikolla: it is $399 now =/
16:56:21 <kmalloc> i think it was $399 when i first looked.
16:56:44 <knikolla> i wouldn't be hard to implement the openid connect protocol in keystone
16:57:16 <cmurphy> lbragstad: well it's not a fully-fledge IdP to start, also openstack's concepts of access control don't really map to access control models for other projects
16:58:01 <lbragstad> i guess i need to see what features are missing the doesn't qualify keystone as a full-fledge idp
16:58:16 <lbragstad> (i totally expect them to be there)
16:58:46 * lbragstad isn't making sense
16:58:54 <lbragstad> I full expect keystone to be missing some of those features
16:58:57 <lbragstad> fully&
16:59:12 <cmurphy> yeah i can explain after the meeting
16:59:18 <lbragstad> ok
16:59:24 <lbragstad> i added it to the etherpad
16:59:47 <lbragstad> just about out of time
16:59:55 <lbragstad> thanks for the time everyone
16:59:59 <lbragstad> see y'all in office hours
17:00:08 <lbragstad> #endmeeting