16:00:04 #startmeeting keystone 16:00:06 Meeting started Tue Oct 16 16:00:04 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:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:09 The meeting name has been set to 'keystone' 16:00:14 #link https://etherpad.openstack.org/p/keystone-weekly-meeting 16:00:14 o/ 16:00:18 o/ 16:00:27 o/ 16:00:49 o/ 16:01:21 we have a lot to get through today - so we'll get started in a minute 16:01:56 O/ 16:02:25 #topic Release status 16:02:35 #info reminder that milestone 1 is going to be next 16:02:36 week 16:02:51 #link https://releases.openstack.org/stein/schedule.html 16:03:08 #info next weeks is the deadline for specification proposals 16:03:11 o/ (better channel) 16:03:13 (more onthat later) 16:03:48 also - it would be good to get as much community goal work squared away before next week as possibl e 16:04:20 #info mutable configuration goal implementation is up for review 16:04:26 #link https://review.openstack.org/#/c/585417/ 16:05:14 #info python3 first goal is nearly complete, and cmurphy is going to put the finishing touches on zuul changes so that keystone runs functional tests in python3 16:05:28 #info the upgrade checker goal implementation is up for review 16:05:33 #link https://review.openstack.org/#/c/608785/ 16:05:47 Do I need to go more official for my 2 Feature-Bugs for Domains and Federation? 16:06:09 https://bugs.launchpad.net/keystone/+bugs?search=Search&field.assignee=ayoung 16:06:36 what's that ayoung? 16:06:46 Is the bug report sufficient process, or do I need a spec? They seem small enough, and explainable enough to me, but then I am the author 16:07:15 um 16:07:16 er 16:07:24 sorry, thought that got the right set of bugs 16:07:27 1 sec 16:07:36 https://bugs.launchpad.net/keystone/+bug/1794527 is right 16:07:36 Launchpad bug 1794527 in OpenStack Identity (keystone) "Allow domain creation with a specific ID" [Wishlist,Incomplete] - Assigned to Adam Young (ayoung) 16:07:53 https://bugs.launchpad.net/keystone/+bug/1641639 is right 16:07:53 Launchpad bug 1641639 in OpenStack Identity (keystone) "use mapping_id for shadow users" [Wishlist,In progress] - Assigned to Adam Young (ayoung) 16:07:56 yeah, those two 16:07:56 looks like https://bugs.launchpad.net/keystone/+bug/1794527 is going to be a spec anyway? 16:08:18 lbragstad, I can. It just seems like busy work. 16:08:26 I think I can explain it just as well in the bug 16:08:53 But...I thought everyone understood the use case, and I'm more interested in making that the case 16:09:06 a spec means spec approval process, etc 16:09:19 and this is more like a tool that can be used for a larger use case, but not tied to it 16:09:25 since we've historically debated this case, i wouldn't mind a spec since it's more intuitive for discussion 16:09:37 well, it really is just a dependency for the other one 16:09:40 in my view 16:10:01 "use mapping_id for shadow users" needs a common domain ID or the user ids change 16:10:12 yeah - that's understandable 16:10:20 i think specs work for this 16:10:33 i honestly am fine with a spec or a bug, if it is a spec, it will need a tracking bug anyway. 16:10:34 these were designed to be as minimal as possible. Spec process means we don't get it this release. 16:10:49 as opposed to trying to debate the justification in bug comments and associating the two 16:11:31 I mean...I could have tried to slip the domain_id change into the other bug, as that is really what is needed to fix it, just figured it was clearer to pull it out into its own 16:11:46 i think it should be it's own 16:11:58 is everyone ok with these changes? Is there any real misunderstanding or objection? 16:12:09 i need to review it again 16:12:12 it's on my list 16:12:15 #topic specifications 16:13:38 https://imgflip.com/i/2k8jz9 <--- OBJECTION 16:13:41 >.> 16:13:42 <.< 16:14:08 i would vote that we propose a specification for the domain id change, because that's always been a hot topic 16:14:14 and it affects the API 16:14:55 it's small enough i could see it being a bug alone. if it's a spec, i expect it to be very very empty 16:15:09 it's the discussion that i'd like to capture 16:15:11 and if people get too picky about the spec's contents, i'd be annoyed. 16:15:21 that and we have specification proposed for review that attempted to do something similar 16:15:37 so, ayoung can you propose a very light spec, anything that is "spec content" should be left to the side of the convo of if this is "good" 16:15:48 convo about merits of the change, not the spec content 16:15:59 and we should review that spec explicitly today/tomorrow 16:16:04 if we are making ayoung post it 16:16:05 ok 16:16:17 ayoung: basic justification. 16:16:27 #action ayoung to propose https://bugs.launchpad.net/keystone/+bug/1794527 as a specification 16:16:27 Launchpad bug 1794527 in OpenStack Identity (keystone) "Allow domain creation with a specific ID" [Wishlist,Incomplete] - Assigned to Adam Young (ayoung) 16:16:36 please keep the bug as the tracker for it 16:16:53 will do 16:17:04 thanks ayoung 16:17:07 and if folks do not register complaints about functionality in the next couple days, I warn you, it's going to be merged :) 16:17:29 if that's the case, socialize it on the mailing list so that it gets proper visibility 16:17:36 #action everyone review justification of ayoung's spec (please do not nit pick the content) 16:17:45 cmurphy is super busy this week 16:18:13 right. this should be a quick review 16:18:29 and should be the core teams #1 review target for discussion 16:18:36 if there is discussion it can wait till S1 day 16:18:51 if there isn't active discussion/dissent we can merge it sooner 16:18:56 i expect this can land. 16:19:03 rememeber that specification freeze is january 11th 16:19:24 but - the earlier the better if we can helpit 16:19:29 exactly 16:19:36 ++ 16:19:37 i expect there will be little dissent on this one 16:19:43 it is straightforward. 16:19:58 so please review it this week. 16:20:02 ayoung outside of those two, do you have other specs to bring up? 16:20:18 lbragstad: also, holy crap jan 11 is a ways down the road for spec freeze :P long cycle is long 16:20:23 I brought jamie's back to life, too 16:20:44 yeah - this release is going to be a marathon 16:20:48 https://review.openstack.org/#/c/607346/ 16:20:56 #link https://review.openstack.org/#/c/607346/ 16:21:01 unscoped catalog 16:21:07 i would love to see this. 16:21:07 that spec was approved, but then backlogged. I brought it back to the front. 16:21:15 And its on the agenda for later, I think 16:21:17 just point blank. 16:21:25 wanna talk it through now? 16:21:36 can we circle back if we have time? 16:21:40 ++ 16:21:51 ++ 16:21:55 just know that it is there 16:22:06 ok 16:22:16 ayoung looks like you have something for read-only role? 16:22:24 so...sort of 16:22:27 it is more than just that 16:22:29 quick backtrack, caching is questionable in a couple ways for py3 16:22:40 just fyi 16:22:45 it will "work"... ish 16:22:54 i need to revisit pymemcache 16:23:31 ok we can move on for read-only role. 16:23:39 Actually, lets go in order 16:23:48 unscoped token...short question 16:23:57 I need to firgure out what to populate in that service catalog 16:24:05 tests do all uuids, even for names, 16:24:17 so I can't just strip out all but 'identity' service 16:24:24 which is what I was origianlly planning on doing 16:24:31 talked it over with jamie last night: 16:24:46 we don't foresee anything in the catalog for unscoped tokens but the identity services 16:24:48 have services (e.g. nova) fixed thier requirement for a project id in the path? 16:24:53 because i know that was an initiative 16:24:55 for a while 16:25:15 i don't think nova uses the project id in the path anymore 16:25:16 does that apply here? 16:25:21 cinder does though 16:25:35 wxy| opened a bug for that with system-scope 16:25:43 this is unscoped catalog only, so no cinder or nova uin the catalog anyway 16:25:54 different subject 16:26:28 what I need to implement is the way to extend access to the catalog API to get the right catalog for unscoped tokens 16:26:37 right, but if we get to the point we're not substituting in projects into the catalog paths... 16:26:39 I'd like it to be something cacheable, 16:26:41 we can render the same catalog 16:26:47 and not care. 16:26:50 got it 16:27:01 :) 16:27:10 so, I was thinking this might be a new (python) API call against the catalog backend 16:27:21 but... 16:27:31 we don't hardcode "identity" anywhere 16:27:37 so...should that be a config option? 16:27:49 hm. no. 16:27:52 like "unscoped_token_services": [identity] 16:28:03 then...what is the "right" way in our world? 16:28:07 you can extend the service data in the api 16:28:19 and add "unscoped_token_service: true" as optional 16:28:28 I can do that 16:28:40 this isn't config, this is system management 16:28:44 I wonder.... 16:28:46 so it should be something done in the api 16:28:54 so, I had a spec for "subcatalogs by id" 16:29:02 could "unscoped" be an id 16:29:20 and we define that as the identity services? 16:29:39 you could just use the current API 16:29:53 https://review.openstack.org/#/c/160909/ 16:29:53 or you could add a new route, auth/catalog/unscoped 16:30:25 you will need to inspect endpoints and any endpoints that have project/other subst in them will be omitted from the catalog 16:30:45 but i think this is pretty straightforward 16:31:15 and we can start with the default (aka bootstrap) populating the unscoped flag for keystone 16:31:36 OK I think I got it. I might add that approach to the spec 16:32:10 we can discuss it there, as I think it will be a big enough change that will merit API level review 16:32:22 ++ 16:32:28 anything else on your specs ayoung ? 16:32:30 ++ 16:32:52 lets move my policy stuff to the end 16:32:56 ok 16:33:27 #topic federated auto-provision improvements 16:33:31 yay! 16:33:33 when is the edge call? 16:33:43 I'll get it on my calendar 16:33:45 iirc 7am pacfic, so... 1400 utc? 16:33:52 so - james penick (from oath) has clearance to open-source their federated auto-provisioning stuff 16:33:55 10am eastern 16:34:10 i *think* 16:34:11 we were talking about it today on the edge call 16:34:22 woot. 16:34:24 #link https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings 16:34:25 that makes me happy 16:34:29 yeah, 10 16:34:32 yeah - no kidding 16:34:42 oath's approach is the correct direction to push 16:34:51 so - he asked if it would be ok if he wrote a spec highlighting the gaps between our implementation and theirs 16:34:53 this makes it much easier. 16:35:02 i would like that very much 16:35:15 we can evaluate from there how far we can push to that implementation without breaking API contracts 16:35:21 and what would need massaging 16:35:30 i think he wants some help with it and said that he can try and get something proposed this week 16:35:43 the spec is key, and as much detail as he can provide 16:35:50 Probably worth making sure we are in sync going in to the summit, too 16:35:50 some of us can chip in for the code 16:35:56 but he was concerned that some of it would be "wrong" 16:36:09 or that we might reject parts of it 16:36:28 the only real rejection i would see is if it breaks API contracts 16:36:35 and we'd need to work around that in either case. 16:36:49 yeah - i'd just be curious to see the implementation and figure out the gaps, then go from there 16:37:07 based upon the edge work (and discussions), I can say I already err to the side of oath is doing it correctly 16:37:26 it is a question of how do we make it work without breaking anyone else [might be extended/new apis] in upstream 16:37:29 but - next week we're going to spend more time on it after james open-sources the code and proposes the specification 16:37:39 and that will happen during the edge call 16:37:42 cool. 16:37:49 i shall try to be there. 16:37:54 good deal 16:37:59 that's all i had for that topic 16:38:00 but 7am is rough because dogs/moring being started 16:38:03 any questions? 16:38:05 I have the time blocked out. I'll also make sure the web meeting tool works 16:38:15 this is zoom, yes? 16:38:18 yeah 16:38:18 correct 16:38:26 i think they finally have a web-only version 16:38:28 which works for me 16:38:36 vs segfaulting my browser 16:38:41 Heh 16:38:44 OK...policy? 16:38:50 yessir 16:39:04 #topic updated policy project 16:39:10 my policy is i dislike policy 16:39:11 >.> 16:39:12 <.< 16:39:17 * kmalloc couldn't resist 16:39:18 Last week, we had a big internal RH conference, and I met a couple people that are doing custom policy for some of our customers 16:39:33 specifically in search of a read only role. THey had it in an internal git repo. 16:39:53 So...I had long had and idea like this on my todo list, but they actually did it. 16:40:04 I want to make this project "short term official" 16:40:15 meaning, eventually all the changes should make their way back to the proejcts 16:40:38 but in the meanwhile, we should have a unified set of policy files that people can use to enforce best practices 16:40:49 does this conflict with the default roles work or system scope/ 16:40:57 I think it complements it 16:41:01 or is it a bandaid until that problem is fully fixed? 16:41:19 lbragstad, bigger than a band aid. More like an iron lung 16:41:31 Lets call it a cast and crutches? 16:41:43 ok 16:42:19 I want to get a set of policies that we can use with TripleO, but...I think this group understands policy better 16:42:43 here is what I have so far: 16:42:53 #link https://pagure.io/openstack-access-policy/tree/common-rules 16:43:02 the master branch is what they have for osp13 16:43:30 I took that and put a mini build system that lets us manage common rules, and built the policy.yaml files with the common sections pre-pended 16:43:38 It needs tests, like, desperately 16:44:21 once I can confirm that we can change the structure of the tests, but still keep things functioning, I want to start working toward mitigation for but 968696 16:44:29 that means first is_admin_project support 16:44:36 and then service scoping 16:44:58 so, i have a single concern 16:45:02 so - i'm already working on tests for system-scope and project-scope support 16:45:13 I don't think we have service scoping in OSP 13. If we do, I'll skip is_admin_project 16:45:20 i dislike "official" projects that are just in place to be deconstructed and deleted long term 16:45:28 it's ... not a huge concern 16:45:40 lbragstad, so, my idea here for tests is to use the oslopolicy-checker and a score card 16:45:43 just a "I don't like the hoops to just puill it apart" 16:45:54 I will confirm that casts have their place 16:46:02 kmalloc, I hear you, but I also have no longer the will to try and get changes into every project out there 16:46:15 this needs to happen in a much faster time line 16:46:18 and i am not saying i object to this project at all 16:46:29 it will be an official project. Just..not sure who will hold the office 16:46:30 just voicing the general "this feels icky" concern. 16:46:46 I can see there being a long term project for the common rules 16:46:47 which sometimes ick is needed to get from A to B 16:47:06 (just detouring a->i->c->k->y->b) ;) 16:47:28 and, then the build system might be to pull the project specific rules from the projects to build the overall policy...or a common library that the projects pull in if we want them to have the definitiev rules in code 16:47:38 this gives us a place to work 16:48:11 actually, since we put the rules in code, we really should have a common python library for common rules 16:48:26 that would be oslo-policy imo 16:48:30 not quite 16:48:35 oslo-policy is a rules engine 16:48:46 but , with the exception of the roles check, it is agnostic of content 16:48:58 this would be oslo-rbac or something like that 16:49:04 this could be like the vendor data in sdk 16:49:11 yep 16:49:17 something that could be extracted from policy eventually 16:49:28 it might belong in olso-policy to start, for ease of deployment 16:49:31 and access 16:49:39 that way it's available to everyone to start 16:49:43 we should probably namespace the common rules, then 16:49:54 common:is_admin etc 16:50:20 that is in line with the consistent policy names lbragstad has proposed 16:50:34 and i support namespacing common rules in a similar/consistent way 16:50:38 merged* 16:51:07 https://bugs.launchpad.net/oslo.policy/+bug/1797739 16:51:07 Launchpad bug 1797739 in oslo.policy "checker CLI does not enumerate all rules for glance" [Undecided,In progress] - Assigned to Adam Young (ayoung) 16:51:14 that is what happens without namespacing 16:51:15 #link https://docs.openstack.org/oslo.policy/latest/user/usage.html#naming-policies 16:51:37 ayoung glance doesn't have policy in code 16:51:43 thay also don' 16:51:56 they also don't have namespacing of their rules. 16:52:25 #link https://review.openstack.org/#/c/501360/ needs to get picked back up 16:52:25 tl;dr: namespace is consistent with the new "policy" for naming-policies. common rules should also be namespaced 16:52:57 so...I don't think this set of policy files/build belongs in oslo.policy, but I am willing to post it there if I get support for it from the rest of the team 16:53:15 my only reasoning is for initial accessibility to the data 16:53:44 if we are adding yet-another-thing, it is something that has to be added everywhere 16:53:54 just trying to make your life easier. 16:54:06 but if you want the harder route, by all means, propose it as a new thing :) 16:54:06 ^ that's why i suggested it being in oslo.policy :) 16:54:40 * kmalloc ^5's lbragstad ;) 16:54:40 (five minutes remaining) 16:55:00 ok...let me rethink how to structure it, so it fits in. I guess a subdir, parallel to oslo-policy named...examples? 16:55:22 It feels wrong to call them examples, as they are supposed to be more production than that 16:55:24 is their main purpose to be referenced or consumed? 16:55:29 consumed 16:55:33 +1 16:55:42 common? 16:55:47 i have one quick last thing before end of meeting 16:55:47 then i'd think it's a sub-dir in oslo 16:56:01 OK...I'll try to come up with a name 16:56:25 but arguable within oslo.policy 16:56:28 kmalloc go ahead? 16:56:32 flask -> Final patches proposed. There are 3 more "change the code" and some moving data, and then a lot of deleting. Please review. it's all done except for merging the last ~10 patches 16:56:43 w00T! 16:56:54 #topic open discussion 16:56:56 the last one is -1800+ lines. 16:57:02 yes it felt good. 16:57:13 lol 16:57:28 +240, -1829 16:57:32 lbragstad: since its a open discussion now. I have some queries regarding unified limits 16:57:42 vishakha go ahead 16:57:53 vishakha: 2min, if it doesn't sneak in we can discuss in -keystone right after 16:58:06 * lbragstad notes that it's super late in japan 16:58:13 lbragstad: I got your point for keeping -1 as min for limits 16:58:45 lbragstad: what can be the max value set for default or resorce limit 16:59:01 i think that depends on the deployer 16:59:17 they should be able to set that to whatever they want 16:59:32 lbragstad: if I tries to set limit for around 1000000000 it gives me 500 server error 16:59:33 so i'm not sure we should implement an upper bound, if that's what you're asking 16:59:45 yes exactly 16:59:56 the upper bound should be defined as what we expect the column length to be 17:00:07 yeah - which would be an implementation detail of sql 17:00:09 so if we specify a unit32, it is the upper limit 17:00:24 so we specify the defined limit as what we use for storage in the initial impl 17:00:33 we can gracefully handle that, but that's about the best we could do i think 17:00:48 pick a number that is within the limit and mark it as upperlimit 17:00:55 500 error is not correct behavior imo 17:00:57 ok . So will raise a bug for it 17:00:59 yeah 17:01:07 vishakha anything else on limits? 17:01:18 should be a bug and Bad Request/Validation error if it exceeds the limit 17:01:46 Yeah one last thing I can set anything for resource name also? 17:01:56 yes 17:02:21 I mean when II tries to list limit for invalid resource name it dont give any error 17:02:25 we don't implement a set of resource - those are open-ended for service developers and operators to define 17:02:30 It lists all the limits 17:02:39 there is again a length max on that data 17:02:49 but otherwise no special nameing requirements 17:03:16 vishakha i believe that is a filtering bug with query parameters GET /v3/limits?resource_name=foobars 17:03:22 returns all limits 17:03:30 because the query parameter is ignored since it doesn't exist 17:04:01 ok got it. Thanks this much for now in unified limits 17:04:08 and that is correct behavior in keystone. 17:04:13 vishakha thanks for jumping in and helping out 17:04:15 thanks for coming everyone, good discussions today 17:04:18 #endmeeting