18:00:09 <lbragstad> #startmeeting keystone
18:00:10 <openstack> Meeting started Tue Nov 28 18:00:09 2017 UTC and is due to finish in 60 minutes.  The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:14 <openstack> The meeting name has been set to 'keystone'
18:00:17 <cmurphy> o/
18:00:21 <lbragstad> o/
18:00:21 <lamt> o/
18:00:22 <raildo> \o/
18:00:23 <hrybacki> o/
18:00:23 <lbragstad> ping ayoung, breton, cmurphy, dstanek, edmondsw, gagehugo, henrynash, hrybacki, knikolla, lamt, lbragstad, lwanderley, kmalloc, rderose, rodrigods, samueldmq, spilla, aselius, dpar
18:00:24 <gagehugo> o/
18:00:27 <KwozyMan> o/
18:00:46 <knikolla> o/
18:00:51 <lbragstad> #link https://etherpad.openstack.org/p/keystone-weekly-meeting
18:00:53 <lbragstad> agenda ^
18:01:12 <rodrigods> o/
18:01:46 <lbragstad> #topic announcements
18:02:01 <lbragstad> #info gerrit cleanup happened last week and this week
18:02:13 <lbragstad> if you noticed things get abandon, that's why
18:02:23 <lbragstad> hopefully the review queue is a bit cleaner
18:02:35 <lbragstad> we can always restore things if we decide to pursue them again
18:02:50 <lbragstad> #info reminder that queens-2 is next week
18:03:17 <lbragstad> which also means that our specification freeze deadline is next week as well
18:03:27 <lbragstad> #link https://releases.openstack.org/queens/schedule.html
18:04:21 <lbragstad> which leads us into our next topic
18:04:26 <lbragstad> #topic Specifications
18:04:42 <lbragstad> I figured we could use the meeting time to cruise through some specifications together
18:04:55 <lbragstad> kind of like an expedited group review
18:05:04 <hrybacki> +1
18:05:09 <knikolla> good idea
18:05:14 <lbragstad> first up
18:05:28 <lbragstad> #topic Specifications: Unified Limits
18:05:30 <lbragstad> #link https://review.openstack.org/#/c/455709/ Limits API
18:05:48 <lbragstad> fresh patch up from this morning
18:06:25 <lbragstad> wxy_: is going to be picking up all that work and has coordinated some of that with sdague
18:08:04 <lbragstad> kmalloc: about your comment on the delete semantics of a limit
18:08:11 <lbragstad> #link https://review.openstack.org/#/c/455709/9/specs/keystone/queens/limits-api.rst,unified
18:08:25 <lbragstad> is that reason enough to have ID for limits?
18:08:44 <lbragstad> #link https://review.openstack.org/#/c/455709/9/specs/keystone/queens/limits-api.rst,unified@257 specifically
18:09:29 <kmalloc> *shrug*
18:09:33 <kmalloc> i prefer no ids.
18:09:42 <kmalloc> and just use a path
18:09:52 <kmalloc> the IDs seem.... weird wedge in there
18:10:00 <kmalloc> but i'd support ids if it makes it that much easier
18:10:12 <lbragstad> ahh
18:10:13 <edmondsw> why is region in there? Shouldn't that come from your token?
18:10:30 <kmalloc> edmondsw: if you have different limits per region.
18:10:49 <edmondsw> oh, nm... region isn't in token
18:10:49 <lbragstad> so instead of using a DELETE with a request body, just put everything on the path
18:10:51 <kmalloc> yeah
18:10:52 <cmurphy> we have ids on pretty much anything, the links thing relies on it
18:11:13 <knikolla> ++ on path
18:11:15 <kmalloc> lbragstad: yeah that is how i'd handle it here. id's feel like a wedge. but again, i'd support either
18:11:39 <lbragstad> id' support everything on the path *or* an ID instead of having a DELETE with a request body
18:12:07 <lbragstad> i wouldn't want someone to be able to use this because what they are using to front keystone trims the body from a delete request
18:12:30 <kmalloc> DELETE with a request body is the only option that worries me
18:12:37 <edmondsw> why are we forcing folks to set region-specific quotas? What if I want a project-specific but not region-specific quota?
18:12:46 <lbragstad> per RFC 7231 in your comment
18:12:50 <kmalloc> edmondsw: we should support region-specifc but not require it
18:13:07 <kmalloc> edmondsw: or at least region-specific overrides.
18:13:16 <lbragstad> also - that's the registered limit
18:13:27 <lbragstad> which is different than a project limit
18:13:59 <lbragstad> which would limit that projects usage in a specific region if i'm understanding thing correctly
18:14:14 <lbragstad> s/thing/things/
18:19:05 <edmondsw> I meant default project limits
18:19:27 <edmondsw> i.e. registered limits at the project level instead of the region level
18:20:03 <edmondsw> or better said... registered limits that aren't region-specific
18:21:00 <lbragstad> services require a region, right?
18:21:26 <kmalloc> lbragstad: uhm...
18:21:30 <kmalloc> maybe?
18:21:34 <kmalloc> i think endpoints do
18:21:41 <kmalloc> services afair do not
18:21:54 <lbragstad> aha
18:22:33 <kmalloc> since the same service def should be used *everywhere*
18:22:44 <kmalloc> but... lets be fair, i could be wrong. the catalog is.... wonky sometimes
18:23:02 <lbragstad> well - regions are apparently optional for endpoints, too
18:23:30 <lbragstad> #link https://github.com/openstack/keystone/blob/19451a8e350ecf6c09159438c14f6c7d16190bb8/keystone/catalog/schema.py#L93
18:23:59 <cmurphy> isn't there always a default region?
18:24:17 <lbragstad> cmurphy: yeah - that's exactly why i thought it was required
18:24:28 <lbragstad> because i thought that same question
18:24:29 <knikolla> no, the default is no region
18:24:54 <lbragstad> ok - so should reqion be optional for limits?
18:25:07 <cmurphy> no, i mean if no region is specified there is a default that will be the region for that endpoint
18:25:16 <cmurphy> the default comes from keystone.conf or something
18:25:18 * cmurphy searches
18:25:41 <lbragstad> #link https://github.com/openstack/keystone/blob/19451a8e350ecf6c09159438c14f6c7d16190bb8/keystone/catalog/core.py#L180
18:26:10 <knikolla> interesting, i clearly remember creating endpoints and having them be part of no region :/
18:26:19 <knikolla> and having to specify region explicitly
18:27:09 <lbragstad> #link https://github.com/openstack/keystone/blob/19451a8e350ecf6c09159438c14f6c7d16190bb8/keystone/catalog/controllers.py#L192
18:27:27 <lbragstad> there is some validation for regions, but i don't see one getting set for endpoints if the request doesn't have it
18:27:28 <edmondsw> https://github.com/openstack/keystone/blob/19451a8e350ecf6c09159438c14f6c7d16190bb8/keystone/catalog/core.py#L165
18:27:36 <edmondsw> ^ would allow for None as region_id
18:27:53 <cmurphy> i might be wrong, it might be just that every deployment tool i've ever used has created one
18:28:03 <lbragstad> yeah - that could be it, too
18:28:08 <cmurphy> i'm not seeing anything in conf/ for it
18:28:47 <lbragstad> to me, i'm not sure it makes sense to require region then if it's possible to have a deployment without a region
18:28:49 <knikolla> http://paste.openstack.org/show/627621/
18:29:18 <cmurphy> okay, i was wrong :)
18:30:21 <lbragstad> i think we'll need to figure that bit out moving forward with that specific spec
18:31:09 <lbragstad> is everyone ok continuing the unified limit stuff in review until next week?
18:31:19 <knikolla> +1
18:31:46 <cmurphy> yep
18:31:47 <lbragstad> #topic Specification: Application Credentials
18:31:50 <lbragstad> #link https://review.openstack.org/#/c/512505/ Application credentials
18:32:08 <lbragstad> this one has shaped up pretty good in the last week or two
18:32:09 <cmurphy> ohai
18:32:31 <lbragstad> cmurphy: you and kmalloc were going through some cases about this last night
18:32:42 <cmurphy> please do read the whole thing and not just the changes, we merged a lot of inconsistencies the last time around because no one read it all the way through
18:32:45 <lbragstad> sounded like we just needed to elaborate on the interactions with trusts?
18:33:09 <cmurphy> oh i forgot to add the bit about blocking trust creation
18:33:32 <cmurphy> other than that it's good to go
18:33:40 <lbragstad> are role assignment APIs blocked, too?
18:33:41 <cmurphy> would be good to get eyes from some of the other stakeholders though
18:34:31 <cmurphy> lbragstad: not in this version, i took out the bits about blocking the whole identity api because my thoughts are that non-admin users can't accidentally delegate those rights anyways
18:34:46 <cmurphy> lbragstad: do you think identity apis should be explicitly blocked?
18:35:24 <cmurphy> anyone else feel strongly about that? ^
18:35:29 <lbragstad> that's a good question - i think we'll need to block some of them (like trusts) but maybe not all
18:36:10 <lbragstad> i suppose role assignment things are admin operations currently
18:36:11 <cmurphy> i think the main concern is preventing self-cloning credentials but i'm otherwise not sure there's a good reason to block anything else
18:36:16 <cmurphy> right
18:37:04 <lbragstad> i'll read through the whole thing after this meeting
18:37:12 <cmurphy> cool
18:37:20 <lbragstad> anyone else have anything to discuss with application credentials that needs to be done here?
18:38:22 <lbragstad> #topic Specification: Policy Goals
18:38:25 <lbragstad> #link https://review.openstack.org/#/c/460344/ Policy goals
18:38:46 <lbragstad> these have been floating around for a while and i'm curious if they're still useful enough to merge
18:38:49 <lbragstad> if not, that's totally fine
18:39:02 <cmurphy> i think they are
18:39:04 * cmurphy will look
18:39:14 <lbragstad> #link https://review.openstack.org/#/c/462733/ Roadmap for security
18:39:18 <lbragstad> falls into the same category
18:39:44 <lbragstad> they are pretty general documents that just lay the introduction for what we need to do to improve u-x in those areas
18:39:53 <lbragstad> they do have some overlap with what is in trello
18:40:09 <lbragstad> but - i figured that is ok since trello is tracking status of all the moving parts
18:41:25 <lbragstad> let me know if you have opinions on what we should do with those
18:41:40 <hrybacki> have to drop, sorry y'all
18:41:50 <lbragstad> hrybacki: o/
18:42:45 <lbragstad> #topic Specification: System Scope
18:42:47 <lbragstad> #link https://review.openstack.org/#/c/464763/ System roles and system scoping
18:42:51 <lbragstad> so - that merged ^
18:42:55 <lbragstad> thanks for all the reviews there
18:43:10 <lbragstad> I do have patches up for the implementation if anyone wants to start reviewing those
18:43:23 <lbragstad> i'll get the rest rebased and reproposed by Dec. 8th
18:43:34 <lbragstad> then i'll go through and formally abandon the global roles stuff
18:43:40 <lbragstad> since that will no longer be relevant
18:44:07 <lbragstad> #topic Specification: Project Tags update
18:44:09 <lbragstad> #link https://review.openstack.org/#/c/508339/ Project tags update
18:44:21 <lbragstad> i must have put this on the schedule before it merged
18:44:26 <lbragstad> so - that happened :0
18:44:36 <lbragstad> #topic Open Discussion
18:44:49 <gagehugo> \o/
18:44:50 <lbragstad> floor is open if folks have things they want to talk about
18:46:44 <lbragstad> cool - looks like we can get some time back before office hours
18:46:50 <lbragstad> thanks for working through the specs
18:46:58 <lbragstad> we should be in good shape by next week!
18:47:08 <cmurphy> \o/
18:47:19 <lbragstad> #endmeeting