18:01:12 #startmeeting keystone 18:01:13 Meeting started Tue May 24 18:01:12 2016 UTC and is due to finish in 60 minutes. The chair is jamielennox. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:16 The meeting name has been set to 'keystone' 18:01:24 :) 18:01:35 ahoy 18:01:45 #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting 18:01:48 o/ 18:02:03 o/ 18:02:17 /o/ 18:02:21 \o\ 18:02:23 haha 18:02:34 ok, as most people are probably aware of by now, stevemar recently had a baby boy and is on leave for the next couple of weeks 18:02:44 whoop whoop! 18:02:48 when does he start reviewing code? 18:02:56 rattle rattle 18:02:58 lbragstad: hehe 18:03:05 who says he isn’t 18:03:20 in reality this means he'll proabably be around, but in the mean time the cores will generally be able to sort out most things for him 18:03:25 o/ 18:03:26 o/ 18:03:34 anything particular come find me or notmorgan 18:03:47 and of course - congrats stevemar 18:03:58 jamielennox: ++ 18:03:59 +1 18:04:02 +++ 18:04:03 +1 18:04:07 jamielennox: lets start w/ the etherpad thing 18:04:25 jamielennox: then we can continue w/ spec freeze etc. 18:04:43 #topic Meeting Agenda Moving to Etherpad? 18:04:51 notmorgan: ok then 18:04:52 Talked with steve and a few others 18:05:01 people cannot edit the wiki because no new accounts are allowed 18:05:08 as a trial i created an etherpad 18:05:11 #link https://etherpad.openstack.org/p/keystone-weekly-meeting 18:05:30 notmorgan: ++ for etherpad 18:05:38 instead of the wiki we can use the etherpad for meetings. any issues/concerns/love the ideas? 18:05:56 all love here 18:05:56 works for me 18:05:57 i'm indifferent - either works for me 18:05:59 just put the etherpad URL in the wiki 18:06:04 rodrigods: that is the plan. 18:06:04 works 18:06:05 makes sense since editing the wiki is a pain 18:06:05 yes 18:06:06 ++ for etherpad, with link in wiki 18:06:09 i wonder how good it will work in a year 18:06:13 works for me (already edited it!) 18:06:20 yea, i'm not too worried either way - works if we can't et people accessing the wiki 18:06:34 ok lets start going from the etherpad then 18:06:41 i've added the spec freeze bit to it 18:06:54 and i'l update the wiki to reference more prominently after this meeting 18:07:06 #action notmorgan fix the wiki keystonemeeting links to point to the new meeting etherpad 18:07:42 hmm, no meetbot confirmations - hope i didn't screw this up 18:07:50 you don't get them on #link or action 18:08:00 ah 18:08:10 #topic Spec proposal freeze is next week, couple of weeks longer for spec freeze. 18:08:25 next week is spec proposal freeze 18:08:49 for anyone unfamiliar this means that any specs you want to land in newton have to be at least proposed by then 18:09:08 we then have a few weeks before specs have to be actually approved to land in newton 18:09:19 so if you're thinking of still proposing something get a wriggle on 18:09:20 is next week 30-5? 18:09:32 breton_: yes 18:09:47 * topol wriggle? I need an Australian dictionary 18:09:50 “get a wriggle on” 18:09:51 notmorgan: i assume it's the end of the week? 18:10:01 jamielennox: yes by end of the week is usually what we aim for 18:10:04 so, will it be unfrozen in 30-5? or frozen on the 30th? 18:10:19 breton_: after the week 18:10:27 so after friday 18:10:36 erm.. wait no. 18:10:40 it will be frozen after the 5th, right? 18:10:46 the spec proposal freeze happens after friday 18:10:51 th... 4th? 18:10:59 3rd. 18:11:01 3rd 18:11:14 after may 3rd is my understanding 18:11:18 yes 18:11:26 so a week from this coming friday is your deadline 18:12:10 #topic Keystone Core Sec Updates 18:12:18 * notmorgan has a lot of topics. 18:12:18 if you're going to be cutting it that close you may want to get moving on it 18:12:33 #link https://launchpad.net/~keystone-coresec 18:12:39 the keystone core sec team is too large 18:12:46 and has a lot of folks not actively participating 18:12:54 i am going to trim this down. 18:12:54 what is coresec? 18:13:01 oh, ok. 18:13:04 breton_: folks who evaluate embargoed bugs 18:13:17 security vulnerabilities 18:13:19 I don't think i'm on that list 18:13:30 notmorgan: i'm on there, but only occasionally comment - so you can trim me if you need to 18:13:31 so, anyone can be on this (does not need to be a core reviewer) 18:13:40 notmorgan, I would like to stay on it 18:13:43 but if you're not interested and are on the list please speak up. 18:13:53 hmm interesting 18:13:54 or if you aren't on the list and are interested... 18:13:56 i feel bad taking up someone's spot if i can't contribute back enough 18:13:56 speak up 18:14:03 i'll conferr with people after the meeting 18:14:06 so think about it 18:14:21 it would be nice to somehow still be able to see what's happening though :-( 18:14:24 is there a limit to how many people we can have? 18:14:31 ideally we should be ~5 people 18:14:45 any one can be looped in to view a security bug 18:14:50 notmorgan because it's security related? 18:14:58 notmorgan: I'd be interested 18:14:59 this is just the front line group who evaluates IF a bug is really a bvlunerability 18:15:13 think about it, i'll work out who will be on the team after the meeting :) 18:15:43 i can guarantee that stevemar will be staying on that list [as ptl] 18:15:58 ok thats all on that topic. 18:16:12 #topic Reviews! 18:16:25 ok 18:16:28 so. 18:16:30 lets do them? 18:16:37 in newton we have been lacking reviews and have a lot of open patches 18:16:43 some can be abandoned, some need rebasing 18:16:44 http://russellbryant.net/openstack-stats/keystone-reviewers-90.txt 18:16:45 ok, guilty as charged. C- for Henry 18:16:49 but in short... we have been lacking reviews 18:16:51 http://stackalytics.com/?module=keystone-group 18:16:56 #link http://stackalytics.com/?module=keystone-group 18:17:02 that is specific to newton code 18:17:11 russ' only covers avg reviews. 18:17:19 this is a call to action for everyone 18:17:21 please review. 18:17:27 cores, non-cores, new folks, etc 18:17:27 I haven't been able to review so much lately due to changes in the job... hoping to get back to it sometime. 18:17:30 will do 18:17:49 question things in the patch if you don't understand (-1s for things that look wrong, but no score with questions help too) 18:17:52 in short. review. 18:18:01 getting back on the review horse 18:18:04 i’ll start reviewing more, whatever my +1 is worth. 18:18:07 my reviews seem to mostly be ignored lately anyways 18:18:08 * rodrigods have some patches that would love reviews 18:18:20 we are actively keeping an eye on folks who are reviewing, get the code base, etc for new cores fwiw 18:18:26 that's because i am on vacation 18:18:32 that's why there are no reviews. 18:18:35 knikolla: it's worth more than you think -- a good review is a good review, regardless who does it 18:18:41 i'm guilty of being low in review count - been tied up with capstone, but that's changing in a day or two 18:18:50 but everyting does need reviews, a +1 means a lot, a -1 with questions/concerns means a lot 18:18:50 i'll be back and we'll be good again, relax. 18:18:56 a +0 with questions means a lot 18:19:00 EVEN if a core already +2'd 18:19:00 I'll review more on this release :) 18:19:03 notmorgan ++ 18:19:13 /kick stevemar 18:19:16 knikolla: ideally you find stuff and it gets fixed before a core comes around and -1's it 18:19:21 please review. we lean on everyones to make the code base good. 18:19:35 and every review matters. 18:19:40 the comments along with the review are worth more than the vote. Try out the change and say what you did 18:19:49 understood, i’ve been mostly commenting with +0 18:19:52 check the coverage report and say if everything is covered 18:19:52 if you have a concern you don't want to say publically, you can talk to a core.. or me directly 18:20:03 the problem with a lot of +0 is they go unnoticed 18:20:06 i'll happily help guide if you're unsure about how to review. 18:20:10 jamielennox: we need to fix that. 18:20:12 I will put more focus on reviewing as well 18:20:21 message heard! 18:20:23 i often miss +0 for ages because it doesn't show up as a change in the review list 18:20:31 No Review Left Behind Act 18:20:33 cores - please do not ignore +0s. submitters, be sure to look for the +0 18:20:35 just as an aside 18:20:36 jamielennox, ++ 18:20:37 with questions. 18:21:13 notmorgan: ok? 18:21:16 and if a +0 is being ignored, raise it up to someone :) don't hesitate to point it out if it seems like it is relevant or change the vote to -1 after conferring with a core 18:21:25 jamielennox: yep :) 18:21:34 submitters should realize that pretty much nothing is going to get merged this release due to lack of reviews. 18:21:43 i usually +1 when i have doubts 18:21:46 (or just change it to -1 if you feel it is important enough) 18:21:48 or a +1 18:21:50 just for the person be able to see 18:21:57 bknudson: yes. so they should be reviewing too! 18:22:02 bknudson: exactlyu 18:22:25 * notmorgan has one more short topic. 18:22:25 #topic Good News Everbody! 18:22:35 so. i've proxied for steve (and talked with him) 18:22:40 and conferred with the cores. 18:22:53 Please welcome rodrigods as the newest member of the core team. 18:23:00 woot woot! 18:23:02 congrats to rodrigods 18:23:03 rodrigods congrats! 18:23:03 o/ 18:23:06 YAY congrats rodrigods! 18:23:07 rodrigods, congrats! 18:23:07 rodrigods, congratulations! 18:23:08 :D 18:23:09 rodrigods: congrats! 18:23:10 i will send an email out after the meeting and get you added to the gerrit group. 18:23:14 well done rodrigods 18:23:14 will i be able to +A all my code? 18:23:15 :) 18:23:19 rodrigods: lol. 18:23:20 thank you all 18:23:22 thanks for all your work on keystone. 18:23:29 rodigods: instant demotion 18:23:35 lol 18:23:40 rodrigods: congrats!!! 18:23:40 shortest core stint award goes to 18:23:51 i want to reiterate that rodrigods has shown understanding of the code base and quality reviews and code. 18:23:51 grats! 18:23:57 s/demo/demoli/ 18:24:17 we are continuing to look for other reviewers/contributors to include in the core group. 18:24:19 thanks! and also for the mentoring since i've joined the openstack community 18:24:46 #action notmorgan to send email and add rodrigods to core group after meeting 18:24:57 rodrigods: congrats 18:24:59 rodrigods: thanks for sticking in there and everything you've done 18:25:13 CONGRATULATIONS rodrigods! Very well deserved! 18:25:49 really glad to be part of the core team, will try to work harder 18:26:00 rodrigods: /salute 18:26:02 rodrigods: you now have +2/+A rights on the keystone repositories. 18:26:30 awesome :) 18:26:48 #topic Creating new versions of keystone component drivers (e.g. V8, V9 etc.) 18:26:57 ok 18:26:58 go go henrynash! 18:27:38 the suspense... 18:27:39 so todate, every time we create a new version of a driver, we archive off an example driver (e.g. SQL) so that we can test we haev not broken teh old interface 18:27:59 some have suggest this is a poor way of doing it.... 18:28:09 …but so far I don’t have any otehr ideas 18:28:18 I guess the old driver is in git already 18:28:22 so maybe check out an old keystone? 18:29:01 microversioned keystone drivers :-) 18:29:02 bknudson: so we usual want to substitute an individual driver 18:29:13 y, check out only that driver. 18:29:42 check out keystone to a new directory and pull out the driver. 18:29:42 check out only that specific driver from git 18:29:49 we used to so this for client testing, I think…but we moved away form it 18:29:54 or maybe you can just check out a file. 18:30:04 that was in a different repo 18:30:12 do we expect people to subclass the driver class directly or duck type it? 18:30:18 you could do git checkout stable/master -- keystone/identity/backend/sql.py 18:30:19 no 18:30:25 (to jamie) 18:30:34 they have to subclass since it's abc. 18:30:44 this is why abc is a bad idea in python 18:30:56 the issue is that we don't want to carry an extra copy of the backend? 18:30:56 we only support the interface, we don’t promise they can subclass our driver and we’ll maintin the code otehyc an continue to subclass 18:31:00 henrynash, is there a problem description somewhere? 18:31:12 just ayiojng objecting in: https://review.openstack.org/#/c/305315/ 18:31:28 I don't mind keeping a copy in the tests, so not sure what the complaints are. 18:31:38 bknudson: ++ 18:31:45 i dont 18:31:47 this is teh current example: we just need to copy the driver so we can test 18:32:00 ayoung: you about? 18:32:01 so where is ayoung to provide an alternative since he complained? 18:32:01 it's not 400 lines that we have to maintain 18:32:02 like having to rely on checking out individual files 18:32:46 henrynash, can we make subsequent interfaces inherited? 18:32:57 ok, so I’ll follow up with ayoung and ask him to calrify his concern and propose an alternative if he feels striongly about it 18:33:01 this will save a lot of copying 18:33:24 the copy is so that we can test with an old implementation 18:33:39 the interface is already inherited 18:33:50 bknudson: ++ 18:33:54 i think we need to maintain those tests, and we need to maintain the symbols so that anyone who subclassed it doesn't get broken immediately 18:34:11 amakarov: it's the copying of the backend 18:34:37 bknudson, I'm about "class IdentityDriverV9(IdentityDriverV8)" 18:35:04 no, we decided to do an adapter 18:35:27 bknudson, well, then we need all the code 18:35:46 amakarov: we wanted to make sure the new driver & interface was as clean as possible…pushing the ugliness into the adaptor 18:36:02 jamielennox: ok, think we ar done on this one 18:36:28 #topic Microversioning of the Identity API 18:36:38 damn. me again 18:37:12 ok, so we have at least one hcnage that requires break api 18:37:21 (hierarchial naming)... 18:37:39 …and the push back from several was that we should really do microversioning now for teh Idenityt API 18:37:45 so this is now proposed: https://review.openstack.org/#/c/315180/ 18:38:17 this is basically teh same approach nova uses, adapted for keystone 18:38:25 this is an API breaking change - the options are: 18:38:33 1) Microversions (like nova) 18:38:42 2) Don't break the API and not change this 18:38:46 3) API V4 18:39:05 in order of my preference [assuming this is something we want] 18:39:07 I re-wrote the origional spec published by ayoung to docuemtn all teh use cases etc and make this a compelte sepc (rather than just refer to the nova spec) 18:39:08 API v4, please no :( 18:39:13 so regards the hierarchical naming (main cause for this) - is that something we can solve with an api version change? it seems like a modelling problem 18:39:21 considering how hard it is to get other projects to even use current features I'd vote for don't break the api. 18:39:33 v4 is least disruptive 18:39:55 henrynash: why do we need this relaxed naming? 18:40:03 I'm here 18:40:17 is there a real use case we're missing that uniqueness per domain is unacceptable? 18:40:23 since domains are not hierarchical 18:40:23 can we put the new stuff on a different path (make it a different resource)? 18:40:25 * samueldmq reads up 18:40:36 jamielennox, policy enforcement for ex. 18:40:58 jamielennox, we can do it in keystone for RBAC3 18:40:59 bknudson: the issue is projects would leak through into the old api...or you'd need a new api to see the project? 18:41:04 notmorgan: so I think there are two things here: we can argue whether we can get away with naming uniquenss or not…..but I think it is better we agree to our approach of hwo we modify the API when we need to….and I’m sure we will need to 18:41:10 bknudson: that's what i would vote for. new/different API resources 18:41:13 bknudson: also it's really an /auth request 18:41:14 I don't see why relaxing a rule is breaking the contract, but I'm not going to fight this fight. If microversions buy us things elsewhere, and this is a good place to introduce them,lets do it 18:41:17 notmorgan: project name is unique in a domain, we can't have a parent and a subproject with the same name 18:41:25 how can we prevent leaking to the old api in any case? 18:41:36 raildo: i don't see that as a problem 18:42:02 it's not just a parent problem 18:42:03 notmorgan: we can have something like, coke->dev and pepsi->dev 18:42:19 raildo: so make coke_domain and pepsi_domain 18:42:23 an accounting project and a engineering project both want to create ProjectX 18:42:36 that name is only unique via the path 18:42:42 so on the specific naming issue, I think it is untennable that as hiearchies grow, that all leaves/nodes have to be unique 18:42:54 jamielennox: and i'm going to argue that accounting should be a domain and engineering should be. 18:42:56 notmorgan: yes, but this doesn't work for reseller, since we can create subprojects acting as domains 18:43:14 cant* 18:43:33 raildo: again, i'm back to domains. 18:43:50 henrynash: so what part of the API is being broken? just getting error codes (4xx) where we used to get success (2xx)? 18:43:51 everything still works with a new domain. 18:44:01 inc. "reseller" concepts. 18:44:05 notmorgan, jamielennox: I guess I am more interested in whether we think we must be able to break teh API in teh future, and if so, how shoudl we do it.... 18:44:07 add a domain to the account. 18:44:21 henrynash: microversions or V4 18:44:36 henrynash: and i'm fine with either 18:44:45 auth is part of defcore, so we have to be mindful about interop 18:44:47 henrynash: given that other projects are adopting microversions, i'd say we would do that - but i would like to be left with absolutely no other choice 18:44:47 lets not V4 18:44:52 though microversions seems to be the pattern for openstack 18:45:04 micro changes are microversions. A big version jump is just going to be ignored 18:45:09 yea, particularly around the auth apis 18:45:25 dtsanek: teh specific problem is that before thsi proposed change, teh proejct scope of “test” would work, but mioght now aftewards, since “test” is not unqiue and /“dev/test” would be requied 18:45:27 if we did a big api version jump, we'd need to extract auth to /auth 18:45:31 not //auth 18:45:43 notmorgan: ++ to that anyway 18:45:49 I'm not sure we are not just making busywork for ourselves, but if this is the cautious approach, it probably is the better way to go 18:45:51 that whole tie auth to the CRUD api is what caused us so much headache in api verion adoption 18:46:01 anyway 18:46:08 ayoung: it is the conservative approach 18:46:20 and keystone frankly needs to err to the conservative side 18:46:30 notmorgan: ++ 18:46:31 notmorgan: I have to agree with you 18:47:02 i'm also wondering if we have a real world request for this yet or are looking at upcoming pain points? 18:47:27 given the adoption of hierarchies so far.. 18:47:52 jamielennox: so mine is the only one I knwo of so far….although if we do the work and never incremenent teh microversion number, nothing breaks anywya 18:48:14 nova used microversions for all sorts of fixes 18:48:16 jamielennox, we have requests 18:48:20 i'll argue that almost everything that is desired with reseller could be done with domains. 18:48:22 useful ones like better validation of user input 18:48:35 on the topic of hierarchies. 18:48:35 bknudson: agreed, and I plan to copy their approach 18:48:37 bknudson: ++ 18:48:46 HMT is limited by other projects, but we want to keep it that way, and stay ahead of the demand 18:48:59 notmorgan: ++ 18:49:09 we had a customer ask about it. Horizon support needs to come up 18:49:10 also with microchanges we might be able to have better adoption of our newer apis 18:49:30 2-3 more minutes so we can leave time for the last topic 18:49:45 we've seen that better adoption only comes when we spend our time in the other projects 18:50:01 ok, so review the spec….and we’ll go from there 18:50:05 bknudson: ++ no one else does auth work 18:50:28 henrynash: my view would be microversions is the answer, but only when we're really sure what we want to solve with it 18:50:42 so i'd prefer to discuss the hierarchical naming problem 18:50:48 it can be useful for other stuff 18:50:50 not only HMT 18:50:59 HMT was the trigger, but... 18:51:05 jamielennox: the use cases will come once it’s there 18:51:09 i think that in a way microversions are an API/architecture smell 18:51:13 maybe a necessary one? 18:51:36 rodrigods: it can, but we've kept our api stable for a while now 18:51:37 dstanek: ++ 18:51:38 dstanek, part of the issue is that Keystone is not really a micros service 18:51:46 if we could design things perfectly from the beginning we wouldn't need it, but we're not perfect. 18:51:48 its more of just a service, not a macro one. THat would be nova 18:51:55 bknudson, ++ 18:52:00 even in nova i'd argue that it's not great architecture 18:52:06 nova is a macros service 18:52:09 its like 15 things 18:52:12 Keysteon is about 5 18:52:21 ok, review spec 18:52:25 I'm surprised every time someone says openstack servers are microservices. 18:52:27 jamielennox: so the spec that is up: (there are two alternatives): https://review.openstack.org/#/c/310048/ and https://review.openstack.org/#/c/315180/ 18:52:29 bknudson: or it we understood hypertext 18:52:41 auth, id & federation, assignment, resource, policy, 18:52:52 #topic Multiple datacenters 18:52:55 each could and should be separate if we were serious about microservies 18:53:01 Ah 18:53:10 amakarov: was hoping to give you a bit more time there, sorry 18:53:14 jamielennox, beyond Fernet? 18:53:34 are you guys going to wrap up and skip this topic? 18:53:39 ayoung: microservices is really abot team size. so if the same team manages all the microservices then splitting won't matter 18:53:46 we should get a best practice written up about Fernet key rotation 18:53:48 amakarov: or i can leave it for next week and put you in first instead? 18:54:10 jamielennox, I think 5 min is anough for now 18:54:15 agrebennikov is here 18:54:30 And the case is described in etherpad 18:54:46 so I tried to explain in details what I need 18:54:57 and this is actually a very common request from the customer 18:55:04 link to pad? 18:55:10 I believe last time we agreed that admin CAN specify project IDs, right? 18:55:18 so to my mind if you are replicating role ids, project ids and user ids in all regions then you are pretty much replicating the database anyway 18:55:21 https://etherpad.openstack.org/p/keystone-weekly-meeting 18:55:45 jamielennox, no, this is not quite correct 18:56:07 db replication means if you broke it in one place - it gets broken in all others 18:56:23 and we actually had this issue in production cloud 18:56:35 why is DB replication an issue since there will be few writes? 18:56:35 that is why the customer decided to get rid of this 18:57:22 without writing UUID there is little to break in Keystone DB now 18:57:22 shaleh, because nobody wants to deal with additional instance of db specifically for keystone 18:57:25 have you tried the read-only database conenctions for this? because if that doesn't work for this case i'm in big trouble :) 18:57:35 agrebennikov: so the alternative is to manually do replication? 18:57:36 which has to have different peers than all other dbs 18:58:06 agrebennikov, I hear ya, LDAP is already replicated 18:58:26 ldap only provides users 18:58:28 dstanek: a push model on the occasional new user / role / project change would not be too bad. But this is still an additional DB instance 18:58:39 ayoung we have something similar to what you're suggesting in the fenret FAQ 18:58:41 and groups 18:58:41 so I do not see the request 18:59:04 agrebennikov, is this essentially "we need to be able to say what the projet Id is" but also for roles and assignments? 18:59:11