18:01:58 #startmeeting keystone 18:01:58 Meeting started Tue Jul 15 18:01:58 2014 UTC and is due to finish in 60 minutes. The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:00 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:01 so this agenda is super long 18:02:03 The meeting name has been set to 'keystone' 18:02:14 really, quick off agenda: 18:02:18 hi 18:02:23 #topic Juno milestone 2 18:02:25 is next week 18:02:37 the last thing i snuck on there can be punted to -keystone if needed post meeting 18:02:43 lbragstad needs a ton of code review attention 18:02:44 https://launchpad.net/keystone/+milestone/juno-2 18:02:55 api validation! 18:03:16 and i threw the GET /v3/catalog stuff up yesterday - need an API review and implementation is ready as well https://blueprints.launchpad.net/keystone/+spec/get-catalog 18:03:22 so, moving on... 18:03:35 more process stuff! 18:03:35 o/ 18:03:49 #topic Spec Proposal Deadline and Spec Approval Deadline 18:03:55 #link https://wiki.openstack.org/wiki/SpecProposalDeadline 18:03:58 #link https://wiki.openstack.org/wiki/SpecApprovalDeadline 18:04:09 be aware that we'll be putting these into affect for j3 18:04:23 O/ 18:05:00 i'm not 100% on dates, but IIRC, if you want to land a blueprint in j3, you'll need a the -spec by the end of j2 (?) 18:05:08 dolphm, ++ 18:05:17 dolphm, why are both needed? 18:05:26 we've got a load of approved specs already 18:05:33 topol: mostly to spread the review load 18:05:44 dolphm, K 18:05:48 at some point we have to review code and not specs 18:05:56 ++ 18:05:59 bknudson ++++ 18:06:02 and also have to be working on fixing things rather than adding new features 18:06:10 ++ 18:06:17 bknudson on a roll 18:06:23 #topic What we did decide WRT format of the specification documents 18:06:30 gathering +s 18:06:38 so, i think we need to rollback the "stop here" change :( 18:06:41 bank the +'s bknudson 18:06:58 dolphm, why 18:07:06 I'm fine with the stop here change. 18:07:24 but I also thought we discussed putting them in "next" rather than "juno" 18:07:43 bknudson: after going through the motions as a spec writer, i found the whole thing overly complicated 18:07:59 dolphm, which part? 18:08:04 and the diffs in gerrit were hard to follow - it ended up as a delete in next/ and an add in juno/ 18:08:20 dolphm, that makes sense 18:08:30 topol: proposing a problem description to next/ 18:08:32 ah thats right next *spaced on that* 18:08:34 and then moving it 18:08:39 dolphm, if its ahrd for you to follow some of us will never make it home 18:08:46 topol: ++ 18:09:02 we could have the proposal filled in for next and then a separate move to juno 18:09:16 bknudson: that's just more process :( 18:09:22 I wouldn't have a problem having filled-in specs in next 18:09:29 dolphm +++. Less process would be good here 18:09:44 i want a clicky interface that targets a spec to juno /soapbox 18:09:47 we should define the reqs for the process and make one that works 18:09:49 not a git commit :P 18:09:56 maybe we could do it with votes? termie's solution was to always start with a -2 until the author had demonstrated a clear reason to need the proposed change. 18:10:10 if we have backlog -> release process/paperwork. 18:10:15 if you start with a -2 no one will look at it 18:10:15 dolphm, ugggh 18:10:19 do we want a monster page of gerrit reviews in -specs? 18:10:27 jamielennox I agree 18:10:35 there are downsides to that, both for author experience and reviewer experience 18:10:39 seems like we'd want to get them accepted 18:10:47 jamielennox: ++ 18:10:48 plus dolphm started his thought with termie's solution :-) 18:11:07 haha 18:11:15 ML topic? if there is general support, file the spec? 18:11:20 I got in my car and pulled away when I saw that 18:11:27 in the short term, i'll propose a revert to the "stop here" language, and we can talk about an alternative path forward from there? 18:11:30 I have to say that I personally don’t mind the “slightly shorter version” we came up with... 18:11:36 dolphm sounds good 18:11:37 i don't mind a long list of specs in gerrit 18:12:05 henrynash I liked it too 18:12:26 since the reviews aren't going to time out and I wouldn't expect rebase issues then I guess it's not an issue to have reviews in gerrit 18:12:32 ++ 18:12:32 henrynash, topol, i wrote up a spec (a simple one) last night, the shortend version helped 18:12:37 what if the short version had a link at the end to point to post implementation design details? 18:12:40 #link https://review.openstack.org/107133 18:12:47 proposal to revert language ^ 18:13:04 so we're still excluding some of the topics however? 18:13:04 dolphm, +2 18:13:18 lbragstad: yes 18:13:19 lbragstad, yeah, we're just reverting the "STOP HERE" part 18:13:20 ok 18:13:24 cool 18:13:25 lbragstad: the ones still in the template are ++ 18:13:44 so we get the benefit of the short version and a pointer if you want more details 18:13:55 #topic Dropping the milestone-2 deadline for API impacting blueprints 18:14:05 this works for me 18:14:28 so i sent an email to the list about this yesterday: 18:14:29 #link http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg29415.html 18:14:46 dolphm, i am in support of this. as long as we are open to re-evaluate at the summit and see how it went 18:15:01 i expect no issues, but worth keeping an open mind on it 18:15:10 dolphm, your arguments seemed a little specious :-) 18:15:10 is anyone *opposed* to dropping this deadline, and *wants* to keep it? (and is willing to present a defense for it?) 18:15:22 I am ok with dropping it 18:15:35 But Im not sure I bought all of your justifiaction 18:15:45 dolphm, I like overly restrictive, draconian deadlines that are immutable. can we make it juno-1 instead? :P 18:15:53 morganfainberg: =) 18:15:56 I like dropping the K3 deadline. We do something in Keystone, no one is going to use it for at least two releases anyway 18:16:08 topol: you're welcome to make another argument in favor of dropping it, i just wanted to share my perspective on it :P 18:16:17 ayoung: K3? milestone 2? 18:16:25 J3, K3 .... 18:16:35 lol k3, wow, future looking there ;) 18:16:37 they are right next to each other on the keyboard 18:16:52 ayoung: ++, i've never seen anyone really use anything we add to keystone in that last cycle 18:16:56 dolphm: I wanted to include hierarchical multitenancy https://review.openstack.org/#/c/107133/ still in Juno, a lot of thing has already implemented. 18:17:01 ayoung, reality, might be more accurate than just a typo in some cases. 18:17:06 I think just that things are more stable and less changes to keep track of and we feel we can relax it a little 18:17:17 raildo, i don't think it is unreasonable. 18:17:18 i think it's very needed this release, we got so bogged down with specs 18:17:23 alright, if no one is opposed, let's call it a thing of the past right now. that means Identity API v3.3 will be considered *stable* when we cut proposed/juno 18:17:33 ++ 18:17:35 topol, and we will re-evaluate at the summit 18:17:43 want an official vote? 18:17:47 wait 18:17:49 are there changes to core api proposed? 18:17:49 topol, worst case is K we move back to milestone2 if it was a big fiasco 18:17:54 morganfainberg: why? 18:17:58 ayoung: nah, only if there are people willing to defend keeping it 18:18:01 wont you have at least some point of freezing 18:18:03 which seems to be no one 18:18:18 raildo, rephrase: it's totally reasonable to get it in this cycle 18:18:19 what yuou said is changes up to the bitter end 18:18:24 morganfainberg: ++ 18:18:30 we got burned in havana doing that with LDAP 18:18:37 morganfainberg: ah, ok. 18:18:59 topol: we still have SAD and SPD, and feature proposal freeze 18:19:02 topol we still have feature freeze 18:19:03 topol, that wont change 18:19:03 we'll still have changes right to the end 18:19:09 OK then 18:19:17 i should have mentioned those in the email 18:19:26 that's when the new deadline would be for these kinds of things 18:19:32 topol this just extends our change window to j3 18:19:33 topol, rather than 1 week from now 18:19:38 topol, if it affects the API 18:19:54 morganfainberg ++++ maybe I misundersatood what dolphm meant 18:20:15 topol: we're just not putting *extra* restrictions on api impacting changes anymore 18:20:17 "when we cut proposed juno" 18:20:21 morganfainberg: I think I already have 50 ~ 70% of the implementation ready. 18:20:27 dolphm, I agree 18:20:32 raildo, yeah thats why i said it's totally reasonable :) 18:21:25 and it does feel more agile not to freeze at j2 :-) 18:21:27 raildo: I still think the spec is not sufficient, so we need to get that tightened up 18:21:30 #info no more early milestone-2 deadline for API-impacting changes 18:21:33 henrynash, ++ 18:21:37 alright, moving on because long agenda... 18:21:48 #topic REST API for retrieving config options 18:21:55 #link https://review.openstack.org/#/c/106558/ 18:21:55 henrynash: I tried to explain you there 18:22:03 security hole!!! 18:22:09 :-) 18:22:18 so i -1'd this earlier today because it sounds like it belongs in oslo, as there's nothing keystone-specific about this 18:22:19 raildo, henrynash, lets circle up after in -keytone, but i think the concerns are resolvable 18:22:20 seems like there is a lot of resistance to this on the ML 18:22:27 ok 18:22:37 dstanek: there's a thread for this? 18:22:42 ok 18:23:00 dolphm, can we please follow the oslo rule of "make it work in a project first" here? 18:23:12 maybe what's needed is a concrete example of how it's to be used. 18:23:12 I don't want to push broken code to oslo just sto sync it back down 18:23:19 buahaha, i opened that bug 18:23:20 #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/040272.html 18:23:22 dolphm, dont oslo things need to be proved out in a project and then moved to oslo after they show value? 18:23:27 ayoung: then make it work first on stackforge - i don't think it belongs in our tree 18:23:31 topol, +_+ 18:23:42 morganfainberg: thanks 18:24:00 morganfainberg: thx. 18:24:06 dolphm: yes, I have to agree….although it’s not so much resistance againstthe idea as to whether it is needed in conjunction with everything else available 18:24:08 topol: but there's nothing relevant to keystone for us to prove out. this is literally exposing oslo.config via generic middleware 18:24:16 let me be upfront and say I don't see the usecase. but... to be fair i don't know what exactly you're solving henrynash, i am open to being swayed to it being valuable 18:24:20 dolphm, I think that is now the standard response for all new features; stackforge first.... 18:24:26 I think people responding to the discussion on the mailing list are thinking that there's better ways to get config done... 18:24:32 e.g., use chef or puppet 18:24:35 henrynash: do you have a usecase at IBM for it? 18:25:02 and i dislike exposing configs via rest, logs can be aggregated to see what the results are and chef/puppet/tripleo/whatever is better about configuring things 18:25:06 ayoung: i don't want to waste keystone-core's time supporting a feature that doesn't belong in the tree 18:25:06 bknudson, yeah, but chef and puppet say what you want it to be, not what it actually is. 18:25:08 but if chef or puppet don't work in some scenario then we have a different requirement that the proposal would fulfill 18:25:08 unless we open the door to do live-rest-based-config-changes. 18:25:11 dolphm, someone still should try something before it goes to oslo 18:25:19 dstanek: we do…and it’s as dscribed 18:25:20 dolphm, I agree..and I think most new things should be done out of tree first. 18:25:20 something new like this 18:25:31 that was the idea of "everthing is an extension" 18:25:33 but I’m happy to do this out of tree to start 18:26:00 morganfainberg: ++ i remember looking a while ago at being able to do config via a REST API and was told that everyone uses puppet (eg) for this sort of thing anyway 18:26:02 henrynash: i'd suggest stackforge/oslo-config-middleware =) 18:26:09 henrynash, it should be trivial to do as middleware that consumes oslo.config out-of-tree 18:26:12 dolphm, ++ 18:26:29 so i'm in general anti it being in projects unless there is good reason that i haven't seen yet 18:26:46 ok, let’s take this one off the list 18:26:54 dolphm, henrynash. Im fine with that. Thats what happened to pycadf and then folks brought it back in. Sweet justice :-) 18:27:09 jamielennox, it's because we use python and not tomcat, if we used tomcat people would love live-config-changes (or C++ with a draconian restart policy **previous job) 18:27:43 I implemented a REST API that re-read the config file for a previous project... worked pretty well. 18:27:47 henrynash, hey if people love it, it'll be easier to get directly into oslo.config or associated rather than needing it in keystone then elsewhere 18:27:59 morganfainberq: ++ 18:28:00 morganfainberg ++ 18:28:07 morganfainberg: ++ 18:28:10 alright... 18:28:10 #topic Defaulting keystonemiddleware.auth_token to use Identity v3 18:28:12 sounds like bknudson just signed up for work 18:28:20 dolphm, lets do it! 18:28:32 bknudson, kill -1 type behavior? 18:28:34 I thought it would default to version discovery? 18:28:35 we are ready for that??? 18:28:47 so shardy noted on the mailing list that we're not using v3 with auth_token yet, and the way to change that behavior by default is this: 18:28:49 topol it passes gate last we checked 18:28:50 #link https://review.openstack.org/#/c/106819/ 18:29:05 morganfainberg, woow. thats progress 18:29:06 dolphm, i also responded to shardy's email this morning indicating we were working on it actively. 18:29:10 unfortunately, proof that this changes passes gate is here: 18:29:11 #link https://review.openstack.org/#/c/106833/ 18:29:21 so i don't undestand this, the only thing that isn't doing v3 is the initial auth request - and when we do a release of client we can consume all that loading from config work to fix that 18:29:31 dolphm, nova change is merged iirc 18:29:32 cinder is 1x+2 waiting for a 2nd 18:29:33 until we move over all projects from keystoneclient.middleware.auth_token to keystonemiddleware.auth_token 18:29:35 I'm surprised that normal version discovery wouldn't work here. 18:29:36 morganfainberg: woot 18:29:36 i'll harass jgriffith today 18:29:45 morganfainberg: is there a bug number on those changes? 18:29:56 morganfainberg: i wanted to advertise it at today's cross-project meeting 18:30:02 dolphm, uhm... they're bknudson's changes 18:30:02 not sure. 18:30:06 make sure every project is aware and onboard 18:30:07 bknudson: ? 18:30:08 there wasn't a bug 18:30:21 bknudson: can we make one, and retroactively mark it as fixed in nova? :) 18:30:31 i just was piggybacking on his reviews (he gets all the credit! he did the work in the code) 18:30:35 yes, I'll make a bug after the meeting. 18:30:44 bknudson: thanks! ping me with the number 18:30:47 my changes were easy 18:30:58 although ceilometer was a pain 18:31:06 since they were referencing internal variable 18:31:09 bknudson, i think they are still -1 on it 18:31:15 I don't know if they'll like my change. 18:31:18 so back to the point at hand-- anyone aware of a reason we shouldn't default to v3 in keystonemiddleware today, and release that as 1.1.0? 18:31:31 or release *soon* 18:31:32 bknudson, but that was for unrelated reasons 18:31:37 bknudson, if they're referencing an internal variable, they're doing it wrong, i'm happy to go argue with them on that 18:31:42 s/argue/discuss 18:31:44 :) 18:31:51 dolphm: I'm confused why we can't use normal version discovery to get the version to use? 18:31:56 it's implemented in keystoneclient 18:32:01 morganfainberg: s/discuss/lecture/ 18:32:02 (unless you want to) 18:32:09 dolphm, ++ 18:32:24 bknudson: we do basically use discovery. the order of preference currently prefers v2 when it finds both 18:32:30 bknudson: my change reverses the default preference 18:32:32 bknudson: it's not the review i was thinking of - all this review should do is prioritize v3 over v2 if available 18:32:43 which seems logical to me 18:32:49 jamielennox: ++ 18:32:54 ok, we can switch to normal version discovery later. 18:33:24 we actually had v3 as the preference a long time ago, but it broke nova. jamielennox recently fixed that breakage (by providing a normalized catalog to nova) 18:33:33 yay jamielennox ! 18:33:45 morganfainberg: ++ 18:33:46 bknudson: yep, once we land the auth plugins and session in middleware using the proper discovery object will be easier 18:34:02 jamielennox was missed in San Antonio 18:34:09 topol, +++++++ 18:34:18 * jamielennox missed San Antonio too 18:34:31 topol, i hear it's cause he just doens't love us enough to fly 18hrs+ each way for 3 days 18:34:37 morganfainberg: ++ 18:34:44 exactly 18:34:51 take one for the team, man 18:35:08 :-) 18:35:09 i'll see what i can do for next one 18:35:15 alright, so i'll leave the discussion up for code review if there's no reason to switch back to WIP: https://review.openstack.org/#/c/106819/ 18:35:30 blame our travel budget more than jamielennox 's dedication 18:35:38 we are just kidding 18:35:45 #topic Migrating non-CADF events to CADF format 18:35:48 topol: (?) o/ 18:35:53 there's no name on this one 18:35:53 18 hours is a long time for 3 days 18:35:54 dolphm, that was me 18:35:57 stevemar: o/ 18:36:03 stevemar: care to edumacate us 18:36:07 sure 18:36:17 this is the notification contract discussion right? 18:36:40 pretty simple, i was questioned as to why we emit some cadf notifications (authN), and some non-CADF (project create and such) 18:36:54 I didn't have a good answer other than, one was implemented first 18:37:09 i was thinking it would be good to get everything in one format 18:37:37 When we first started doing the notification work, cadf was *just* getting off the ground I believe 18:37:38 so tools could more easily consumer things from us, in only one format, not multiple 18:37:43 lbragstad, yep 18:38:15 i wanted to propose it here, see if anyone had any thoughts/ pushback 18:38:19 stevemar: so would this be a matter of emitting two notifications on identity.project.created, for example? or a switch of formats 18:38:37 dolphm, i was thinking switch of formats, but we could do both and deprecate the other 18:38:41 in due time 18:39:31 stevemar: what format are you leaning towards? the cadf format, right? 18:39:50 there's an omg-notifications-ARE-an-API discussion on openstack-dev right now that might have input on that 18:39:55 lbragstad, yes 18:40:07 dolphm, ++ that was what i thought this was in reference to 18:40:19 dolphm, ugh yeah, i saw that, theres a lot going on there, 18:40:24 morganfainberg: was there a trend towards more CADF there? 18:40:33 dolphm, it was suggested? 18:40:35 i haven't read past the first post 18:40:37 hmmm, sometimes we may need to generate both for a transition period :-( 18:40:39 dolphm, same 18:40:41 dolphm, i dunno, it's kindof a dense conversation 18:41:01 topol, configurable 18:41:16 #action stevemar to catch up on the dense mailing list conversation, drag keystone into the convo, and report back next week 18:41:17 topol, let the deployers choose if they need both, or let them disable one if we're doing that 18:41:20 I was at the HK summit meeting and was surprised that ceilometer was putting up with the changes to notifications 18:41:25 yes, but still yuvky 18:41:27 dolphm, ahhh C'MON 18:41:34 Would be better if it can support both format (versioning ?) or configurable. I am working on a barbican change where it will consume these keystone notifications/events. 18:41:36 stevemar: thanks! 18:41:38 stevemar, Voluntold! 18:41:45 dammit rabbit 18:41:52 dolphm, wow...Im speechless 18:41:58 :-) 18:41:58 arunkant: ++ 18:42:07 dolphm is learning from topol 18:42:15 might need to send the message on a different channel 18:42:20 I didnt want to say it but... 18:42:24 dr redundant is a pro 18:42:43 topol: p.s. i have expectations for casual nick friday 18:42:58 #topic Dependency Injection "Fix" 18:43:01 morganfainberg: o/ 18:43:09 #link https://review.openstack.org/#/c/106951/ 18:43:12 o/ 18:43:25 that name is so demeaning. like using the term spirit bunnies in fast time at ridgemont high. only ayoung will get that movie reference 18:43:26 arunkant: that would work. I *think* what is currently sent in a notification is a subset of the cadf standard... so future version should build on/include what we already have. 18:43:31 ok so, dependency injection is overly complex for what we do 18:43:32 lets stop doing it. 18:43:40 dstanek: ? 18:43:42 s/version/versions/ 18:43:59 dolphm: yep, too complex! 18:44:04 lets either pass the dependencies into the objects on init that need it, or reference the registry directly 18:44:08 morganfainberg, really. cause I hate that stuff. makes the code hard to follow 18:44:09 We moved beyong "reference the manager" for a reason.... 18:44:11 make the managers really more like singletons 18:44:19 morganfainberg: ++ 18:44:32 morganfainberg +++ 18:44:32 no singletons 18:44:33 i agree and that dependencies should be passed into the __init__ 18:44:34 oh THIS is what ya'll were discussing #openstack-keystone today 18:44:44 but the current DI has caused us issues and has lots of edge cases 18:44:48 no singletons 18:44:50 i missed the beginning and then had java nightmares wondering wtf 18:44:55 a real DI framework would force you into that anyway 18:44:59 what is casual nick friday??? 18:45:01 bknudson, it was an option, not saying it was the right answer 18:45:17 we don't treat them like singletons anyways (in the tests) 18:45:21 * topol I know dstanek must know a better way to do that stuff 18:45:24 and we can't if we want to do valid testing 18:45:31 bknudson, right. 18:45:39 bknudson, well we could but it would get really really ugly 18:45:52 currently the entire dependency tree get's loaded on the first call anyway - if anything it's better to do it on boot 18:45:55 dependencies should be passed in to __init__ 18:46:02 topol: i started to convert of code to a different DI framework, but the changes were too extensive so i stopped 18:46:04 ayoung, that is perfectly fine by me 18:46:05 we had circular deps at one point. Can we cut those now? 18:46:26 ayoung: between what and what? 18:46:30 we've got a part that builds all the drivers anyways, all it has to do is build the drivers differently, passing in the refs that need it. 18:46:31 ayoung, i think we have. and even if we haven't, the resolution to that is in service.py backendloading 18:46:33 dolphm, identity and assignment 18:46:43 the proxy methods? 18:46:51 is there still a circular dep? 18:47:02 dolphm, no, where identity being LDAP means assignment is LDAP 18:47:05 morganfainberg, yeah the code with the comment, do this one before al the others... 18:47:07 it was one needed the other in some cases for compatibility 18:47:32 this still can be 100% resolved in the backend building code. 18:47:40 so you didn't have to configure the assignment backend, it was derived from the identity backend config 18:47:44 is there a proposal for what we want to do there? or just some ideas? 18:47:55 ++ lets do it right this time 18:48:07 bknudson: ah 18:48:12 needs to be completed before Lebrons contract runs out in 2 years 18:48:17 dstanek: make ldap assignment go away! 18:48:17 this is a relatively easy / minor fix all said and done, lots of simplification 18:48:31 dolphm, i wish :( 18:49:11 dstanek, 2 years 42 million 18:49:17 we need a fantasies/ dir in -specs 18:49:21 welcome home son 18:49:32 now, there is _still_ an issue with class level instantiated objects, but we can just punt and say "who cares". 18:50:01 I don't think you could do that with our DI anyways 18:50:02 e.g. an object instatied at the class definition point can't receive the newest version of the *_api object 18:50:04 but we can work around those special cases. 18:50:09 bknudson, no we can't 18:50:32 bknudson, thats what made me want to rip this all apart in the first place. 18:51:00 dolphm, ldap assignemtn can go away. We can now default assignemet Driver to None. 18:51:02 bknudson, even though i'm not using that functionality in the next update. 18:51:30 optional deps are just evil 18:51:31 ok so, solution: pass dependencies in to the manager init 18:51:32 i think is what i generally heard 18:51:42 morganfainberg, ++ 18:51:47 sounds like the normal way to do it. 18:51:52 nothing fancy 18:51:55 morganfainberg that would be so awesome 18:52:01 easy enough, make the manager base class smarter 18:52:03 yep, magic-less 18:52:06 (not a lot smarter) 18:52:08 it's like putting an umlaut in Luke 18:52:25 lol 18:52:27 just confuses everyone 18:52:29 Or Blue Oyster Cult, for that matter 18:52:40 whats wrong with pütting an umlaut in lüke or anything with a ü. 18:52:52 motley crue. saw them in concert 18:53:01 topol, BOC was first 18:53:01