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