18:01:29 #startmeeting keystone 18:01:29 Meeting started Tue May 10 18:01:29 2016 UTC and is due to finish in 60 minutes. The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:33 hiya 18:01:34 The meeting name has been set to 'keystone' 18:01:39 ping for keystone ajayaa, amakarov, ayoung, breton, browne, crinkle, claudiub, davechen, david8hu, dolphm, dstanek, edmondsw, gyee, henrynash, hogepodge, htruta, jamielennox, joesavak, jorge_munoz, knikolla, lbragstad, lhcheng, marekd, MaxPC, morganfainberg, nkinder, raildo, rodrigods, rderose, roxanaghe, samleon, samueldmq, shaleh, stevemar, tjcocozz, tsymanczyk, topol, vivekd, wanghong, xek 18:01:43 o/ 18:01:44 o/ 18:01:45 hi! 18:01:50 o/ 18:01:52 oh boy, oh boy, oh boy 18:01:57 o/ 18:02:02 o/ 18:02:02 Keystoners do keystone things! 18:02:05 howdy y'all! 18:02:17 O/ 18:02:19 * topol I'm 98% recovered from martinellifluenza 18:02:26 it's a toughie eh topol 18:02:38 topol: you can never be 100% recovered from it 18:02:55 agenda: https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Main_Agenda 18:03:07 :-) 18:03:11 #topic newton release deadlines 18:03:39 i sent this out to the mailing list already, so i'll link it here 18:03:40 #link http://lists.openstack.org/pipermail/openstack-dev/2016-May/093838.html 18:03:44 o/ 18:03:49 * morgan is here 18:03:53 I'll also be updating releases.openstack.org/newton/schedule.html 18:04:01 fail: http://releases.openstack.org/newton/schedule.html 18:04:17 o/ 18:04:18 in general, these are the deadlines: 18:04:21 May 30-03 -> R-18 -> Spec proposal freeze 18:04:22 Jul 04-06 -> R-13 -> Spec freeze 18:04:22 Jul 11-15 -> R-12 -> Feature proposal freeze 18:04:24 Aug 29-02 -> R-5 -> Feature Freeze 18:04:46 * topol are the midcycle dates/location 100% confirmed? 18:04:54 topol: the dates are confirmed. 18:04:58 * stevemar looks at morgan 18:05:08 what are the dates? 18:05:10 topol: it will be in the bay area... but the exact venue will be determined today 18:05:16 sec. 18:05:26 and they are….in calendar dates, not R-xx dates 18:05:29 ? 18:05:40 henrynash: what is they? 18:05:47 teh dates, that is 18:06:10 ahhh Cant wait to goto to Scoma's restaurant 18:06:14 The R-xx dates are alongside the calendar dates 18:06:34 its R-11, wed, thurs, friday 18:06:45 i *think* that is 20, 21, 22 of July 18:06:52 which time zone? 18:06:52 i can;t load the newton schedule/calendar atm 18:06:55 morgan: thx, that’s what I needed 18:06:57 bknudson: :) 18:07:14 R-11 Jul 18-22 18:07:18 morgan: thank you sir 18:07:20 and it will be wed, thurs, friday of that week 18:07:32 we will either be in San Jose, or in San Francisco 18:07:35 Happy Birthday to me! 18:07:36 i asked for the SF office space 18:07:39 http://releases.openstack.org/newton/schedule.html 18:07:41 howdy 18:07:56 because i've heard from cburgess that those offices are amazing 18:07:56 ayoung: today…or at the midcycle? 18:08:02 henrynash, mid cycle 18:08:13 18 July I officially turn middle aged 18:08:16 ayoung: cake, me things 18:08:18 thinks 18:08:24 ayoung: we'll need to get you a cake 18:08:26 but we will go with whichever cisco is willing to offer us, neither will be bad. 18:08:31 Candy is Dandy but 18:08:36 (also Cisco is hosting us, FYI) 18:08:41 morgan: free routers for everyone! 18:09:04 If only it was free routers for everyone... 18:09:05 stevemar: ask cburgess about that, i'm not promising free anythings ;) 18:09:07 yesss!!!! i'll need at least 48 ports on mine 18:09:07 thank you cisco 18:09:12 liquor is quicker! What did I win? 18:09:21 cburgess: :) 18:09:36 will dial up be avail? 18:09:37 cburgess: is it more? 18:09:40 topol: buying the first round 18:09:47 I should get the answer on final location this afternoon. There is a planning meeting for the event. 18:09:57 Sure.. why pot 18:09:59 thanks cburgess ! 18:09:59 not 18:10:15 topol: :-) 18:10:15 morgan + cburgess thanks for hosting us! :) 18:10:17 cburgess: and pass on the gratitude of the keystone team for hosting us. 18:10:25 Absolutely 18:10:29 +++ Tahnks morgan and cburgess 18:10:33 ++ 18:10:42 ++ 18:10:46 ++ 18:10:59 ++ 18:11:06 aside from midcycle, is everyone OK with the dates I proposed? lots of run way still 18:11:22 you can see how they line up with the release schedule: http://releases.openstack.org/newton/schedule.html 18:11:27 just to reiterate - it will be Mon July 18th - Wed July 20th 18:11:37 lbragstad: nope, Wed - Fri 18:11:40 ah 18:11:53 lbragstad: "14:06 morgan: its R-11, wed, thurs, friday" 18:11:55 so Wednesday the 20th - Friday the 22nd 18:12:20 yeppers 18:13:02 i wonder if i'll be allowed to add the midcycle dates to the newton schedule.. guess i'll find out 18:13:30 i'll get http://releases.openstack.org/newton/schedule.html updated by eod 18:13:52 stevemar: you should ask ttx :) 18:14:15 morgan: i'll find out when i include it in the patch :) 18:14:23 hehe ok 18:14:35 #topic PTL back up 18:14:41 WFM 18:15:01 starting May 25th, i'll be out for 3-4 weeks, i don't think this is a surprise to most 18:15:24 jamielennox volunteers / i suckered him into it... to back me up 18:15:29 volunteered* 18:15:35 voluntold 18:15:40 wow exciting times! 18:15:47 stevemar: OMG 18:15:52 ayoung: ++ 18:16:02 stevemar: that's coming soon! 18:16:04 so just a heads up, i'll be transferring over the whip to him :) 18:16:28 I'll go find my men at work album to get ready 18:16:30 stevemar, any special permissions he's going to need, in order to unstuck things? 18:16:32 maybe a pinch of voluntold'ing 18:16:33 o/ 18:16:34 stevemar: i'll also volunteer to cver things while jamie is asleep 18:16:49 ayoung: see morgan's comment 18:16:52 ayoung: nope. no special perms except stable branch things and doclph and i can handle that 18:16:53 thanks jamielennox and morgan 18:16:54 we are letting Jamie sleep? 18:17:01 I figured he still had the launch codes 18:17:20 Keystone team meeting moving ahead 8 hours. 18:17:22 i expect morgan and dolphm to help jamie when needed 18:17:45 i haven't asked them, i just assume these things 18:18:24 i don't think the meeting time will move, just jamie will have to wake up early 18:18:25 * morgan hasn't needed to fill in for stevemar much cause stevemar is mostly up late pacific time as well. 18:18:48 that's how i roll. in other timezones. 18:19:09 okie, next topic 18:19:13 any other q's? 18:19:17 just wait till every two hours becomes a timezone for you :-) 18:19:24 topol: ++ 18:19:36 :) 18:19:39 #topic ldap and py3 18:20:14 at the summit, i asked why we don't just use pyldap instead of python-ldap (and not bother with ldap3) 18:20:23 the short answer was: we need ldappool too 18:20:42 i finally looked into it, the whole lib is only a few hundred lines 18:20:43 do we? 18:20:46 stevemar, any reason to not do both? 18:20:52 ayoung: no 18:20:56 because ldapool was *mostly* an eventlet solution 18:21:06 we can hold onto normal connections etc now. 18:21:13 considering the mess that is the ldap code base, we would like to have the ldap3 style code cleanup 18:21:16 anyway, crinkle helped me out here, but we got ldap tests passing py3 https://review.openstack.org/#/c/311827/ 18:21:19 like one would with traditional python (multiprocess) 18:21:26 although, to be fair, the ldap code itself could be cleaned up with out that 18:21:53 the kicker is, we had to bring the ldappool code in-tree 18:22:00 ayoung, ++ for ldap3 :) 18:22:03 eh, not the worst thing 18:22:07 can we drop ldappool? 18:22:11 ldapool has pretty much be left dead. 18:22:16 since ldappool hasn't accepted any PR in years 18:22:17 and i'm ok with carrying it locally. 18:22:21 if we need it 18:22:23 ayoung: it has benefits 18:22:24 instead of bringing it in to the tree, just cut out using it? 18:22:34 where's the unit tests for ldappool? 18:22:35 in fact, i'll even sign up to help maintain it if we need it 18:22:47 ayoung: i remember mfisch saying it netted him a nice gain 18:22:53 bknudson: i dind't pull those in tree yet 18:22:59 bknudson: this was just a poc 18:23:11 also nice work stevemar and crinkle 18:23:19 :) 18:23:26 i'm not even sure if we can legally do this.... so i asked here: http://lists.openstack.org/pipermail/legal-discuss/2016-May/000404.html 18:23:43 stevemar: what is the original license of ldappool? /me goes and looks 18:23:47 self.bacend = backend 18:23:52 they misspelled baconed. 18:23:58 bknudson: lol 18:24:05 mmm bacon 18:24:19 stevemar: this can't be included like this in-tree iirc 18:24:23 stevemar: this is MPL 18:24:25 not APL 18:24:31 ::sadface:: 18:24:36 yep 18:24:40 MPL/LGPL 18:24:43 we can't do this like this 18:24:47 we can fork/fix it 18:24:48 why do we need ldappool? 18:24:48 so somehow we'd need to get the author to agree to relicense. 18:25:04 bknudson: nah, fork/fix and publish it again if we need. 18:25:15 or we rewrite the parts we need. 18:25:24 dstanek: it nets real gains: http://www.mattfischer.com/blog/?tag=ldap 18:25:42 stevemar: lets take this convo offline. 18:25:53 i think i have some things to contribute to help on this front one way or another. 18:25:54 alrighty 18:26:06 we don't need ldappool if we switch to ldap3 18:26:07 stevemar: morgan: yes, i'd like to figure what we actually need here instead of carrying dead weight 18:26:09 i'll bug you and crinkle later on and we'll figure it out. 18:26:15 bknudson: why not? 18:26:18 and dstanek 18:26:26 ldap3 has connection pooling built-in. 18:26:31 bknudson: nice 18:26:40 "Finally I’m using the eventlet (keystone-all) vs apache2 to run Keystone." 18:26:47 lets drop pool 18:27:08 it would need a deprecation cycle 18:27:19 anyway, like morgan said, we can circle back to this topic 18:27:34 stevemar, dstanek, crinkle: tossed a -2 on the current review for the MPL/LGPL, but saying this here so it doesn't halt work. we just *cant* import it like that. 18:27:35 stevemar, nope. We can drop it for python3 only, no? 18:27:47 not because it shouldn't be included. 18:27:56 ayoung: that is hard to do. 18:28:09 stevemar, so are we decided to use pyldap instead of ldap3? 18:28:16 a big old six.PY3 wrap around everything 18:28:26 roxanaghe: not yet, just weighing the options 18:28:32 roxanaghe: we can have both 18:28:59 using pyldap would be a nice rip and replace of the existing code 18:29:03 stevemar, ok so nobody will shout at me if I continue to put up some patches with ldap3? 18:29:26 roxanaghe: of course not :) 18:29:41 morgan +++ keep the LGPL out :-) 18:29:57 topol: i actually don't mind LGPL. 18:30:07 but different convo for a different time 18:30:08 roxanaghe: nope, if you want to work on it they i say go for it 18:30:09 stevemar, pfew :) 18:30:25 morgan, perhaps over scotch in SFO 18:30:39 * topol yes I'll buy 18:30:42 topol: needs to happen before that :P 18:30:46 anyway 18:30:50 #topic Help update the API-ref site 18:30:51 dstanek, stevemar I just want to see how easy the unit tests code would be - replacing that fakeldap server would be a huge advantage for using ldap3 18:31:10 bknudson: do you know much about this? 18:31:17 roxanaghe, ++ 18:31:20 a bit. 18:31:20 the API-ref site update-a-mania 18:31:31 they want to move the API-ref site off wadls and to RST 18:31:35 apparently the nova team is having a 2 day event for it 18:31:40 so sdague developed some sphinx plugins. 18:31:55 and there's a tool to convert WADL to RST 18:32:14 so someone needs to run the conversion and post the RST into keystone 18:32:31 "into keystone"? 18:32:32 probably just look at nova and see where it is. 18:32:37 openstack/keystone repo 18:32:54 or keystone-specs? 18:32:58 like this: https://github.com/openstack/nova/tree/master/api-ref/source ? 18:33:03 although I think the idea is to put it in keystone 18:33:08 we already have keystone-specs that has RST 18:33:29 looks different enough 18:33:33 We intentionally keeps specs separate from Keystone 18:33:33 the problem with keystone-specs is that it doesn't match what the server implements. 18:33:44 Keystone is the reference implementation of the identity API, but not the only 18:33:54 so for example we merged some specs that changed the API and then they didn't get implemented 18:34:00 so the API docs didn't match the server. 18:34:02 ah 18:34:07 i see 18:34:08 bknudson: yeah, specs are great to find design discussions, but not so much as documentation 18:34:15 disagree 18:34:17 stevemar: I volunteer 18:34:29 samueldmq: thank you 18:34:31 there is a reason this is a human driven effort 18:34:32 I was planning to start this work last cycle, but had some other priorities 18:34:39 samueldmq: do you have enough to get started? 18:34:50 samueldmq: put your name here: https://wiki.openstack.org/wiki/Documentation/Migrate#API_Reference_Plan 18:34:52 samueldmq: you can ping annegentle or sdague i guess 18:34:52 (remove me) 18:35:02 stevemar: I think so, I ask them if I need more clarity 18:35:05 the API spec is designed to be where we explain not just the values, but the intention. You can't automate that 18:35:05 and yeah, add your name to the wiki 18:35:06 :) 18:35:07 samueldmq: there are ML threads about this topic too, if you haven't seen them 18:35:10 We'll end up with Javadocs 18:35:43 Ending up with docs like the java std library would be awesome. 18:35:49 * samueldmq nods 18:35:58 bknudson, that is not the same thing 18:36:24 bknudson, we'll end up with javadocs like most projects have that have one page per attribute with nothing explaining them. 18:36:28 ayoung: i think they are looking for a consistent representation of what "keystone" can do, and what APIs that openstack services support. consistent being key here. We're the only team that has the API in the specs repo 18:36:30 ayoung: i'm assuming you mean the amount of crap you can to put in code comments for tools? 18:37:01 dstanek, I mnean the amount of generated text you get from an API that is all boilerplate and no substance 18:37:20 bring dolphm in to this discussion, I hate arguing as his proxy 18:37:24 stevemar: ++ the current seperation of API spec is weird, and problematic 18:37:30 I mean, I agree with him, but he says it much better 18:37:33 ayoung: this looks nice to me: http://developer.openstack.org/api-ref-compute-v2.1.html 18:38:07 the result will look exactly like this: http://developer.openstack.org/api-ref-identity-v3.html 18:38:18 that's the point of the conversion tool is it looks the same as what we have. 18:38:37 except it's rst rather than wadls 18:39:14 stevemar: ++ 18:39:39 api-guide explain the concepts, like what is role assignment, etc (scheduling for nova, eg) 18:39:50 So longas we keep our Current API docs too, and note the difference, it will probably be OK. 18:39:53 while the api-ref gives a list of APIs and their details 18:40:20 samueldmq: thanks for volunteering 18:40:34 if we keep the current API spec then we'll have to maintain things in 2 places. 18:41:18 bknudson: ideally we keep one, i'd still like to see APIs proposed with specs 18:41:27 stevemar: np, I like this kind of work :) 18:41:28 but maybe that is not a reality 18:41:30 it's my pleasure 18:41:31 the reason nova is having a multi-day sprint is because their API docs were so out of sync with the implementation 18:41:56 stevemar: we have to strive for one and one only 18:42:18 henrynash: and the api-ref site seems to be winning that battle 18:42:29 stevemar: agreed 18:42:47 MEH. 18:43:16 henrynash, your next 18:43:18 #topic 18:43:21 fail 18:43:25 #topic Relaxing project name constraints 18:43:26 #topic Relaxing project name constraint 18:43:29 henrynash: ^ 18:43:30 ok 18:43:43 #link https://review.openstack.org/#/c/310048/ 18:43:55 henrynash, YAY! 18:43:56 so this is something we have talked about in the past 18:44:13 time to relax 18:44:17 henrynash, we are only going to do that if the "strict" thing is on? 18:44:20 now that we have hierarchies, our “project name must be unique across the whole hiearcy” seem weird 18:44:24 ayoung: yes 18:44:31 ++ 18:45:09 i thought the whole "strict" thing was in regards to project ids? 18:45:26 basically I’d like people’s feed back on teh consequences of this….for instance, should we return a project path wherever we have a name today? or only when we really really need to 18:45:35 stevemar: no, name 18:45:36 henrynash: yeah, that seems to not be inline with the reseller usecase 18:45:41 Anyone not think that this is the obvious right thing to do? 18:45:46 stevemar: no, it’s names 18:45:48 henrynash: i am still against this. 18:46:03 henrynash: so it would always be a project path for the name? 18:46:10 it violates the v3 spec, which states projects within a domain must be unique 18:46:15 gyee: exactly 18:46:21 gyee: yes, we are changing the spec 18:46:24 henrynash: unless we move to microversions, i'm a -2 on this 18:46:25 but they are 18:46:27 unique 18:46:29 keystone v4? 18:46:32 it violates api stability 18:46:35 or keystone v4 18:46:38 I'm feeling there might be problems with other projects 18:46:43 that was a fundamental requirement for v3 18:47:12 i don't understand how users would know what to pass or how we would know if they are passing path or name 18:47:15 there are still projects stuck on v2.0 18:47:22 so my request is, read the spec, where I go through al lteh issues you raise, and give feedback 18:47:36 henrynash, yes sir, will do 18:47:51 v3.14 18:48:04 3.14159 18:48:19 * morgan has put a comment on the spec 18:48:22 and a -2. 18:48:22 dstaneK: I agree - one issue (in a multi cloud scenario) - is how do you knwo if a particuar cloud has this (optional) cap abilit enabled 18:48:23 sorry. 18:48:39 morgan, how would microversions help? Can you walk through that, cuz if it does, I am all for them 18:48:44 however, i think this is a case where microversion inclusion is the correct path going forward 18:48:48 morgan: as long as you describe why (in exact terms), then I can respond 18:48:53 henrynash: i did. 18:49:21 ayoung: if we move towards microversions we can lock out duplicated names (i think) 18:49:40 ayoung: so we only support specific domains / hierarchies under the new microversion? 18:49:56 this is one area we cannot fuck up as keystone auth is also part of defcore 18:50:05 morgan, so that is what we were going for with the config option. Does a microversion mean a version on a subset of the API? 18:50:07 ayoung: i think*. but lets be fair, we can't break the contract that names are unique without exploring the right path forward. 18:50:21 ayoung: i'd follow nova's template 18:50:29 ayoung: for how the microversion works. 18:50:32 tbh 18:50:39 morgan, can we get the cliff notes version? 18:50:48 I tried following the mailing list and it was a swarm 18:50:55 never got to what they landed on 18:50:56 ayoung: entire api is microversioned 18:51:00 afaik 18:51:13 so any minor change gets a minor version bump? 18:51:20 yeah 18:51:22 but it is negotiated explicitly in the client 18:51:26 microversioning is not semver 18:51:34 so the client would say "i use ver 22 of the the API" 18:51:41 and get ver 22 semantics 18:51:41 the number just keeps going up 18:51:50 it is monotonically increasing 18:51:50 and they can break whatever they want in a new version 18:51:51 what if.... 18:51:55 ok heres a thought 18:52:02 bknudson: not "whatever" but. yes much more flexible 18:52:05 and there has not been thoughts on when we stop supporting older versions. 18:52:10 suppose we say that you create with the short name, but then we tell you the long name 18:52:13 does that end up creating lots of technical debt.. supporting lots of versions?? 18:52:41 so if you create with "BAR" but put it under "BAR" you get projectname="FOO/BAR" 18:52:50 s/technical debt/jobs for america/ 18:52:55 topol: yes. the thought has been to periodically raise the oldest supported version but it has not happened in practice yet 18:52:57 ayoung: possivle. 18:53:00 possible* 18:53:18 morgan: so does ANY chaneg of the API have to be versioned using this method (e.g. we have a config option that , if set, means you can’t use reserved chars in a project name….is that “breaking” the api?)? 18:53:20 cburgess: ^ cc (see dtroyer's comment) re convo we had about microversions 18:53:25 and then the new thing is "short_name" or something that is additive to the API instead of changing the meaning.... 18:53:38 trump would say to just default on our technical debt. 18:53:42 henrynash: yep. though the reservation of characters is likely an easier change microversion wise. 18:53:45 bknudson: lol 18:53:51 bknudson, we can always print more code 18:53:58 morgan dtroyer makes sense and I suspect will be inevitable 18:54:12 henrynash: if it is breaking the stable contract it needs a way to address such as microversions 18:54:20 this is a proposed break of the stable contract. 18:54:20 dtroyer, reminds me how everyday in Austin stevemar ordered greater amounts of BBQ poundage at Coopers 18:54:22 morgan, OK, so can we take your -2 as "this must depend on microversions?" 18:54:35 bknudson i think he'd just try and declare bankruptcy for tech debt 18:54:39 ayoung: yes. it needs to address not breaking the stable contract 18:54:45 once we have a way forward, my -2 is lifted 18:54:52 morgan: ok. fair enough! 18:54:57 ayoung: and i commented as such with the -2 :) 18:55:05 henrynash: you've got some spec'ing to do 18:55:05 5 minutes left 18:55:11 the stable contract is the *only* reason i'm -2 on this fwiw. 18:55:39 i think it is 100% reasonable. 18:55:40 the thing is, this is more liberal than what we have now. So we would not break existing deployments, but that is not what you are saying, is it 18:55:40 * topol wondering how much code it takes to implement a microversion framework... 18:55:57 stevemar: (separate subject) I have one BP that I think doesn’t need a spec: https://blueprints.launchpad.net/keystone/+spec/domain-config-as-stable 18:56:07 ayoung: it would change the behavior in a way that is not consistent with our current v3 api 18:56:14 cool, i'll add it to the pile 18:56:19 ayoung: that is the concern. more liberal or less, it is still a contract brack 18:56:21 break* 18:56:28 stevemar: not sure when we look at those 18:56:34 henrynash: definitely doesn't need a spec 18:56:43 morgan, so a user needs to be able to query to know which contract is in effect? 18:56:54 topol: Nova has started extracting carefully-selected bits into a lib for doing the hard part, the negotiation… 18:56:55 ayoung: yes. (or the client at least) 18:56:55 the user specifies. 18:57:08 bknudson: ++ 18:57:10 dtroyer: nice. 18:57:15