18:01:58 <dolphm> #startmeeting keystone
18:01:58 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:01 <dolphm> so this agenda is super long
18:02:03 <openstack> The meeting name has been set to 'keystone'
18:02:14 <dolphm> really, quick off agenda:
18:02:18 <raildo> hi
18:02:23 <dolphm> #topic Juno milestone 2
18:02:25 <dolphm> is next week
18:02:37 <morganfainberg> the last thing i snuck on there can be punted to -keystone if needed post meeting
18:02:43 <dolphm> lbragstad needs a ton of code review attention
18:02:44 <dolphm> https://launchpad.net/keystone/+milestone/juno-2
18:02:55 <lbragstad> api validation!
18:03:16 <dolphm> 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 <dolphm> so, moving on...
18:03:35 <dolphm> more process stuff!
18:03:35 <topol> o/
18:03:49 <dolphm> #topic Spec Proposal Deadline and Spec Approval Deadline
18:03:55 <dolphm> #link https://wiki.openstack.org/wiki/SpecProposalDeadline
18:03:58 <dolphm> #link https://wiki.openstack.org/wiki/SpecApprovalDeadline
18:04:09 <dolphm> be aware that we'll be putting these into affect for j3
18:04:23 <ayoung> O/
18:05:00 <dolphm> 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 <morganfainberg> dolphm, ++
18:05:17 <topol> dolphm, why are both needed?
18:05:26 <dolphm> we've got a load of approved specs already
18:05:33 <dolphm> topol: mostly to spread the review load
18:05:44 <topol> dolphm, K
18:05:48 <bknudson> at some point we have to review code and not specs
18:05:56 <lbragstad> ++
18:05:59 <topol> bknudson ++++
18:06:02 <bknudson> and also have to be working on fixing things rather than adding new features
18:06:10 <dolphm> ++
18:06:17 <topol> bknudson on a roll
18:06:23 <dolphm> #topic What we did decide WRT format of the specification documents
18:06:30 <bknudson> gathering +s
18:06:38 <dolphm> so, i think we need to rollback the "stop here" change :(
18:06:41 <stevemar> bank the +'s bknudson
18:06:58 <topol> dolphm, why
18:07:06 <bknudson> I'm fine with the stop here change.
18:07:24 <bknudson> but I also thought we discussed putting them in "next" rather than "juno"
18:07:43 <dolphm> bknudson: after going through the motions as a spec writer, i found the whole thing overly complicated
18:07:59 <topol> dolphm, which part?
18:08:04 <dolphm> 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 <topol> dolphm, that makes sense
18:08:30 <dolphm> topol: proposing a problem description to next/
18:08:32 <morganfainberg> ah thats right next *spaced on that*
18:08:34 <dolphm> and then moving it
18:08:39 <topol> dolphm, if its ahrd for you to follow some of us will never make it home
18:08:46 <dolphm> topol: ++
18:09:02 <bknudson> we could have the proposal filled in for next and then a separate move to juno
18:09:16 <dolphm> bknudson: that's just more process :(
18:09:22 <bknudson> I wouldn't have a problem having filled-in specs in next
18:09:29 <topol> dolphm +++. Less process would be good here
18:09:44 <morganfainberg> i want a clicky interface that targets a spec to juno /soapbox
18:09:47 <bknudson> we should define the reqs for the process and make one that works
18:09:49 <morganfainberg> not a git commit :P
18:09:56 <dolphm> 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 <morganfainberg> if we have backlog -> release process/paperwork.
18:10:15 <jamielennox> if you start with a -2 no one will look at it
18:10:15 <topol> dolphm, ugggh
18:10:19 <bknudson> do we want a monster page of gerrit reviews in -specs?
18:10:27 <topol> jamielennox I agree
18:10:35 <dolphm> there are downsides to that, both for author experience and reviewer experience
18:10:39 <bknudson> seems like we'd want to get them accepted
18:10:47 <dolphm> jamielennox: ++
18:10:48 <topol> plus dolphm started his thought with termie's solution :-)
18:11:07 <dstanek> haha
18:11:15 <morganfainberg> ML topic? if there is general support, file the spec?
18:11:20 <topol> I got in my car and pulled away when I saw that
18:11:27 <dolphm> 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 <henrynash> I have to say that I personally don’t mind the “slightly shorter version” we came up with...
18:11:36 <topol> dolphm sounds good
18:11:37 <stevemar> i don't mind a long list of specs in gerrit
18:12:05 <topol> henrynash I liked it too
18:12:26 <bknudson> 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 <ayoung> ++
18:12:32 <morganfainberg> henrynash, topol, i wrote up a spec (a simple one) last night, the shortend version helped
18:12:37 <topol> what if the short version had a link at the end to point to post implementation design details?
18:12:40 <dolphm> #link https://review.openstack.org/107133
18:12:47 <dolphm> proposal to revert language ^
18:13:04 <lbragstad> so we're still excluding some of the topics however?
18:13:04 <morganfainberg> dolphm, +2
18:13:18 <dolphm> lbragstad: yes
18:13:19 <morganfainberg> lbragstad, yeah, we're just reverting the "STOP HERE" part
18:13:20 <lbragstad> ok
18:13:24 <lbragstad> cool
18:13:25 <dolphm> lbragstad: the ones still in the template are ++
18:13:44 <topol> so we get the benefit of the short version and a pointer if you want more details
18:13:55 <dolphm> #topic Dropping the milestone-2 deadline for API impacting blueprints
18:14:05 <bknudson> this works for me
18:14:28 <dolphm> so i sent an email to the list about this yesterday:
18:14:29 <dolphm> #link http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg29415.html
18:14:46 <morganfainberg> 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 <morganfainberg> i expect no issues, but worth keeping an open mind on it
18:15:10 <topol> dolphm, your arguments seemed a little specious  :-)
18:15:10 <dolphm> is anyone *opposed* to dropping this deadline, and *wants* to keep it? (and is willing to present a defense for it?)
18:15:22 <topol> I am ok with dropping it
18:15:35 <topol> But Im not sure I bought all of your justifiaction
18:15:45 <morganfainberg> dolphm, I like overly restrictive, draconian deadlines that are immutable. can we make it juno-1 instead? :P
18:15:53 <dolphm> morganfainberg: =)
18:15:56 <ayoung> 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 <dolphm> 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 <dolphm> ayoung: K3? milestone 2?
18:16:25 <ayoung> J3, K3 ....
18:16:35 <morganfainberg> lol k3, wow, future looking there ;)
18:16:37 <ayoung> they are right next to each other on the keyboard
18:16:52 <jamielennox> ayoung: ++, i've never seen anyone really use anything we add to keystone in that last cycle
18:16:56 <raildo> 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 <morganfainberg> ayoung, reality, might be more accurate than just a typo in some cases.
18:17:06 <topol> 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 <morganfainberg> raildo, i don't think it is unreasonable.
18:17:18 <stevemar> i think it's very needed this release, we got so bogged down with specs
18:17:23 <dolphm> 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 <ayoung> ++
18:17:35 <morganfainberg> topol, and we will re-evaluate at the summit
18:17:43 <ayoung> want an official vote?
18:17:47 <topol> wait
18:17:49 <bknudson> are there changes to core api proposed?
18:17:49 <morganfainberg> topol, worst case is K we move back to milestone2 if it was a big fiasco
18:17:54 <raildo> morganfainberg: why?
18:17:58 <dolphm> ayoung: nah, only if there are people willing to defend keeping it
18:18:01 <topol> wont you have at least some point of freezing
18:18:03 <dolphm> which seems to be no one
18:18:18 <morganfainberg> raildo, rephrase: it's totally reasonable to get it in this cycle
18:18:19 <topol> what yuou said is changes up to the bitter end
18:18:24 <dolphm> morganfainberg: ++
18:18:30 <topol> we got burned in havana doing that with LDAP
18:18:37 <raildo> morganfainberg: ah, ok.
18:18:59 <dolphm> topol: we still have SAD and SPD, and feature proposal freeze
18:19:02 <morganfainberg> topol we still have feature freeze
18:19:03 <morganfainberg> topol, that wont change
18:19:03 <bknudson> we'll still have changes right to the end
18:19:09 <topol> OK then
18:19:17 <dolphm> i should have mentioned those in the email
18:19:26 <dolphm> that's when the new deadline would be for these kinds of things
18:19:32 <morganfainberg> topol this just extends our change window to j3
18:19:33 <morganfainberg> topol, rather than 1 week from now
18:19:38 <morganfainberg> topol, if it affects the API
18:19:54 <topol> morganfainberg ++++ maybe I misundersatood what dolphm meant
18:20:15 <dolphm> topol: we're just not putting *extra* restrictions on api impacting changes anymore
18:20:17 <topol> "when we cut proposed juno"
18:20:21 <raildo> morganfainberg: I think I already have 50 ~ 70% of the implementation ready.
18:20:27 <topol> dolphm, I agree
18:20:32 <morganfainberg> raildo, yeah thats why i said it's totally reasonable :)
18:21:25 <topol> and it does feel more agile not to freeze at j2 :-)
18:21:27 <henrynash> raildo: I still think the spec is not sufficient, so we need to get that tightened up
18:21:30 <dolphm> #info no more early milestone-2 deadline for API-impacting changes
18:21:33 <morganfainberg> henrynash, ++
18:21:37 <dolphm> alright, moving on because long agenda...
18:21:48 <dolphm> #topic REST API for retrieving config options
18:21:55 <dolphm> #link https://review.openstack.org/#/c/106558/
18:21:55 <raildo> henrynash: I tried to explain you there
18:22:03 <topol> security hole!!!
18:22:09 <topol> :-)
18:22:18 <dolphm> 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 <morganfainberg> raildo, henrynash, lets circle up after in -keytone, but i think the concerns are resolvable
18:22:20 <dstanek> seems like there is a lot of resistance to this on the ML
18:22:27 <raildo> ok
18:22:37 <dolphm> dstanek: there's a thread for this?
18:22:42 <henrynash> ok
18:23:00 <ayoung> dolphm, can we please follow the oslo rule of "make it work in a project first"  here?
18:23:12 <bknudson> maybe what's needed is a concrete example of how it's to be used.
18:23:12 <ayoung> I don't want to push broken code to oslo just sto sync it back down
18:23:19 <stevemar> buahaha, i opened that bug
18:23:20 <morganfainberg> #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/040272.html
18:23:22 <topol> dolphm, dont oslo things need to be proved out in a project and then moved to oslo after they show value?
18:23:27 <dolphm> ayoung: then make it work first on stackforge - i don't think it belongs in our tree
18:23:31 <ayoung> topol, +_+
18:23:42 <dolphm> morganfainberg: thanks
18:24:00 <dstanek> morganfainberg: thx.
18:24:06 <henrynash> 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 <dolphm> 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 <morganfainberg> 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 <ayoung> dolphm, I think that is now the standard response for all new features;  stackforge first....
18:24:26 <bknudson> 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 <bknudson> e.g., use chef or puppet
18:24:35 <dstanek> henrynash: do you have a usecase at IBM for it?
18:25:02 <morganfainberg> 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 <dolphm> ayoung: i don't want to waste keystone-core's time supporting a feature that doesn't belong in the tree
18:25:06 <ayoung> bknudson, yeah, but chef and puppet say what you want it to be, not what it actually is.
18:25:08 <bknudson> 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 <morganfainberg> unless we open the door to do live-rest-based-config-changes.
18:25:11 <topol> dolphm, someone still should try something before it goes to oslo
18:25:19 <henrynash> dstanek: we do…and it’s as dscribed
18:25:20 <ayoung> dolphm, I agree..and I think most new things should be done out of tree first.
18:25:20 <topol> something new like this
18:25:31 <ayoung> that was the idea of "everthing is an extension"
18:25:33 <henrynash> but I’m happy to do this out of tree to start
18:26:00 <jamielennox> 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 <dolphm> henrynash: i'd suggest stackforge/oslo-config-middleware =)
18:26:09 <morganfainberg> henrynash, it should be trivial to do as middleware that consumes oslo.config out-of-tree
18:26:12 <morganfainberg> dolphm, ++
18:26:29 <jamielennox> so i'm in general anti it being in projects unless there is good reason that i haven't seen yet
18:26:46 <henrynash> ok, let’s take this one off the list
18:26:54 <topol> dolphm, henrynash. Im fine with that. Thats what happened to pycadf and then folks brought it back in. Sweet justice :-)
18:27:09 <morganfainberg> 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 <bknudson> I implemented a REST API that re-read the config file for a previous project... worked pretty well.
18:27:47 <morganfainberg> 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 <henrynash> morganfainberq: ++
18:28:00 <topol> morganfainberg ++
18:28:07 <dolphm> morganfainberg: ++
18:28:10 <dolphm> alright...
18:28:10 <dolphm> #topic Defaulting keystonemiddleware.auth_token to use Identity v3
18:28:12 <stevemar> sounds like bknudson just signed up for work
18:28:20 <stevemar> dolphm, lets do it!
18:28:32 <ayoung> bknudson, kill -1 type behavior?
18:28:34 <bknudson> I thought it would default to version discovery?
18:28:35 <topol> we are ready for that???
18:28:47 <dolphm> 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 <morganfainberg> topol it passes gate last we checked
18:28:50 <dolphm> #link https://review.openstack.org/#/c/106819/
18:29:05 <topol> morganfainberg, woow. thats progress
18:29:06 <morganfainberg> dolphm, i also responded to shardy's email this morning indicating we were working on it actively.
18:29:10 <dolphm> unfortunately, proof that this changes passes gate is here:
18:29:11 <dolphm> #link https://review.openstack.org/#/c/106833/
18:29:21 <jamielennox> 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 <morganfainberg> dolphm, nova change is merged iirc
18:29:32 <morganfainberg> cinder is 1x+2 waiting for a 2nd
18:29:33 <dolphm> until we move over all projects from keystoneclient.middleware.auth_token to keystonemiddleware.auth_token
18:29:35 <bknudson> I'm surprised that normal version discovery wouldn't work here.
18:29:36 <dolphm> morganfainberg: woot
18:29:36 <morganfainberg> i'll harass jgriffith today
18:29:45 <dolphm> morganfainberg: is there a bug number on those changes?
18:29:56 <dolphm> morganfainberg: i wanted to advertise it at today's cross-project meeting
18:30:02 <morganfainberg> dolphm, uhm... they're bknudson's changes
18:30:02 <morganfainberg> not sure.
18:30:06 <dolphm> make sure every project is aware and onboard
18:30:07 <dolphm> bknudson: ?
18:30:08 <bknudson> there wasn't a bug
18:30:21 <dolphm> bknudson: can we make one, and retroactively mark it as fixed in nova? :)
18:30:31 <morganfainberg> i just was piggybacking on his reviews (he gets all the credit! he did the work in the code)
18:30:35 <bknudson> yes, I'll make a bug after the meeting.
18:30:44 <dolphm> bknudson: thanks! ping me with the number
18:30:47 <bknudson> my changes were easy
18:30:58 <bknudson> although ceilometer was a pain
18:31:06 <bknudson> since they were referencing internal variable
18:31:09 <morganfainberg> bknudson, i think they are still -1 on it
18:31:15 <bknudson> I don't know if they'll like my change.
18:31:18 <dolphm> 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 <dolphm> or release *soon*
18:31:32 <morganfainberg> bknudson, but that was for unrelated reasons
18:31:37 <morganfainberg> 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 <morganfainberg> s/argue/discuss
18:31:44 <morganfainberg> :)
18:31:51 <bknudson> dolphm: I'm confused why we can't use normal version discovery to get the version to use?
18:31:56 <bknudson> it's implemented in keystoneclient
18:32:01 <dolphm> morganfainberg: s/discuss/lecture/
18:32:02 <morganfainberg> (unless you want to)
18:32:09 <morganfainberg> dolphm, ++
18:32:24 <dolphm> bknudson: we do basically use discovery. the order of preference currently prefers v2 when it finds both
18:32:30 <dolphm> bknudson: my change reverses the default preference
18:32:32 <jamielennox> 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 <jamielennox> which seems logical to me
18:32:49 <dolphm> jamielennox: ++
18:32:54 <bknudson> ok, we can switch to normal version discovery later.
18:33:24 <dolphm> 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 <morganfainberg> yay jamielennox !
18:33:45 <dolphm> morganfainberg: ++
18:33:46 <jamielennox> bknudson: yep, once we land the auth plugins and session in middleware using the proper discovery object will be easier
18:34:02 <topol> jamielennox was missed in San Antonio
18:34:09 <morganfainberg> topol, +++++++
18:34:18 * jamielennox missed San Antonio too
18:34:31 <morganfainberg> topol, i hear it's cause he just doens't love us enough to fly 18hrs+ each way for 3 days
18:34:37 <dolphm> morganfainberg: ++
18:34:44 <topol> exactly
18:34:51 <topol> take one for the team, man
18:35:08 <topol> :-)
18:35:09 <jamielennox> i'll see what i can do for next one
18:35:15 <dolphm> 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 <ayoung> blame our travel budget more than jamielennox 's dedication
18:35:38 <topol> we are just kidding
18:35:45 <dolphm> #topic Migrating non-CADF events to CADF format
18:35:48 <dolphm> topol: (?) o/
18:35:53 <dolphm> there's no name on this one
18:35:53 <topol> 18 hours is a long time for 3 days
18:35:54 <stevemar> dolphm, that was me
18:35:57 <dolphm> stevemar: o/
18:36:03 <dolphm> stevemar: care to edumacate us
18:36:07 <stevemar> sure
18:36:17 <morganfainberg> this is the notification contract discussion right?
18:36:40 <stevemar> 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 <stevemar> I didn't have a good answer other than, one was implemented first
18:37:09 <stevemar> i was thinking it would be good to get everything in one format
18:37:37 <lbragstad> When we first started doing the notification work, cadf was *just* getting off the ground I believe
18:37:38 <stevemar> so tools could more easily consumer things from us, in only one format, not multiple
18:37:43 <stevemar> lbragstad, yep
18:38:15 <stevemar> i wanted to propose it here, see if anyone had any thoughts/ pushback
18:38:19 <dolphm> 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 <stevemar> dolphm, i was thinking switch of formats, but we could do both and deprecate the other
18:38:41 <stevemar> in due time
18:39:31 <lbragstad> stevemar: what format are you leaning towards? the cadf format, right?
18:39:50 <dolphm> there's an omg-notifications-ARE-an-API discussion on openstack-dev right now that might have input on that
18:39:55 <stevemar> lbragstad, yes
18:40:07 <morganfainberg> dolphm, ++ that was what i thought this was in reference to
18:40:19 <stevemar> dolphm, ugh yeah, i saw that, theres a lot going on there,
18:40:24 <dolphm> morganfainberg: was there a trend towards more CADF there?
18:40:33 <morganfainberg> dolphm, it was suggested?
18:40:35 <dolphm> i haven't read past the first post
18:40:37 <topol> hmmm, sometimes we may need to generate both for a transition period :-(
18:40:39 <stevemar> dolphm, same
18:40:41 <morganfainberg> dolphm, i dunno, it's kindof a dense conversation
18:41:01 <morganfainberg> topol, configurable
18:41:16 <dolphm> #action stevemar to catch up on the dense mailing list conversation, drag keystone into the convo, and report back next week
18:41:17 <morganfainberg> topol, let the deployers choose if they need both, or let them disable one if we're doing that
18:41:20 <bknudson> I was at the HK summit meeting and was surprised that ceilometer was putting up with the changes to notifications
18:41:25 <topol> yes, but still yuvky
18:41:27 <stevemar> dolphm, ahhh C'MON
18:41:34 <arunkant> 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 <dolphm> stevemar: thanks!
18:41:38 <morganfainberg> stevemar, Voluntold!
18:41:45 <stevemar> dammit rabbit
18:41:52 <topol> dolphm, wow...Im speechless
18:41:58 <topol> :-)
18:41:58 <dolphm> arunkant: ++
18:42:07 <stevemar> dolphm is learning from topol
18:42:15 <bknudson> might need to send the message on a different channel
18:42:20 <topol> I didnt want to say it but...
18:42:24 <dolphm> dr redundant is a pro
18:42:43 <dolphm> topol: p.s. i have expectations for casual nick friday
18:42:58 <dolphm> #topic Dependency Injection "Fix"
18:43:01 <dolphm> morganfainberg: o/
18:43:09 <dolphm> #link https://review.openstack.org/#/c/106951/
18:43:12 <morganfainberg> o/
18:43:25 <topol> 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 <lbragstad> 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 <morganfainberg> ok so, dependency injection is overly complex for what we do
18:43:32 <morganfainberg> lets stop doing it.
18:43:40 <dolphm> dstanek: ?
18:43:42 <lbragstad> s/version/versions/
18:43:59 <dstanek> dolphm: yep, too complex!
18:44:04 <morganfainberg> lets either pass the dependencies into the objects on init that need it, or reference the registry directly
18:44:08 <topol> morganfainberg, really. cause I hate that stuff. makes the code hard to follow
18:44:09 <ayoung> We moved beyong "reference the manager" for a reason....
18:44:11 <morganfainberg> make the managers really more like singletons
18:44:19 <jamielennox> morganfainberg: ++
18:44:32 <topol> morganfainberg +++
18:44:32 <bknudson> no singletons
18:44:33 <dstanek> i agree and that dependencies should be passed into the __init__
18:44:34 <dolphm> oh THIS is what ya'll were discussing #openstack-keystone today
18:44:44 <morganfainberg> but the current DI has caused us issues and has lots of edge cases
18:44:48 <ayoung> no singletons
18:44:50 <dolphm> i missed the beginning and then had java nightmares wondering wtf
18:44:55 <dstanek> a real DI framework would force you into that anyway
18:44:59 <topol> what is casual nick friday???
18:45:01 <morganfainberg> bknudson, it was an option, not saying it was the right answer
18:45:17 <bknudson> 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 <bknudson> and we can't if we want to do valid testing
18:45:31 <morganfainberg> bknudson, right.
18:45:39 <morganfainberg> bknudson, well we could but it would get really really ugly
18:45:52 <jamielennox> 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 <ayoung> dependencies should be passed in to __init__
18:46:02 <dstanek> topol: i started to convert of code to a different DI framework, but the changes were too extensive so i stopped
18:46:04 <morganfainberg> ayoung, that is perfectly fine by me
18:46:05 <ayoung> we had circular deps at one point.   Can we cut those now?
18:46:26 <dolphm> ayoung: between what and what?
18:46:30 <bknudson> 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 <morganfainberg> ayoung, i think we have. and even if we haven't, the resolution to that is in service.py backendloading
18:46:33 <morganfainberg> dolphm, identity and assignment
18:46:43 <dolphm> the proxy methods?
18:46:51 <dolphm> is there still a circular dep?
18:47:02 <morganfainberg> dolphm, no, where identity being LDAP means assignment is LDAP
18:47:05 <topol> morganfainberg, yeah the code with the comment, do this one before al the others...
18:47:07 <morganfainberg> it was one needed the other in some cases for compatibility
18:47:32 <morganfainberg> this still can be 100% resolved in the backend building code.
18:47:40 <bknudson> so you didn't have to configure the assignment backend, it was derived from the identity backend config
18:47:44 <dstanek> is there a proposal for what we want to do there? or just some ideas?
18:47:55 <ayoung> ++  lets do it right this time
18:48:07 <dolphm> bknudson: ah
18:48:12 <topol> needs to be completed before Lebrons contract runs out in 2 years
18:48:17 <dolphm> dstanek: make ldap assignment go away!
18:48:17 <morganfainberg> this is a relatively easy / minor fix all said and done, lots of simplification
18:48:31 <morganfainberg> dolphm, i wish :(
18:49:11 <topol> dstanek, 2 years 42 million
18:49:17 <dolphm> we need a fantasies/ dir in -specs
18:49:21 <topol> welcome home son
18:49:32 <morganfainberg> now, there is _still_ an issue with class level instantiated objects, but we can just punt and say "who cares".
18:50:01 <bknudson> I don't think you could do that with our DI anyways
18:50:02 <morganfainberg> e.g. an object instatied at the class definition point can't receive the newest version of the *_api object
18:50:04 <morganfainberg> but we can work around those special cases.
18:50:09 <morganfainberg> bknudson, no we can't
18:50:32 <morganfainberg> bknudson, thats what made me want to rip this all apart in the first place.
18:51:00 <ayoung> dolphm, ldap assignemtn can go away.  We can now default assignemet Driver to None.
18:51:02 <morganfainberg> bknudson, even though i'm not using that functionality in the next update.
18:51:30 <dstanek> optional deps are just evil
18:51:31 <morganfainberg> ok so, solution: pass dependencies in to the manager init
18:51:32 <morganfainberg> i think is what i generally heard
18:51:42 <ayoung> morganfainberg, ++
18:51:47 <bknudson> sounds like the normal way to do it.
18:51:52 <bknudson> nothing fancy
18:51:55 <topol> morganfainberg that would be so awesome
18:52:01 <morganfainberg> easy enough, make the manager base class smarter
18:52:03 <jamielennox> yep, magic-less
18:52:06 <morganfainberg> (not a lot smarter)
18:52:08 <bknudson> it's like putting an umlaut in Luke
18:52:25 <hrybacki> lol
18:52:27 <bknudson> just confuses everyone
18:52:29 <ayoung> Or Blue Oyster Cult, for that matter
18:52:40 <morganfainberg> whats wrong with pütting an umlaut in lüke or anything with a ü.
18:52:52 <topol> motley crue. saw them in concert
18:53:01 <ayoung> topol, BOC was first
18:53:01 <henrynash> ayoung: on your feet, or on your knees…
18:53:09 <stevemar> i'd appreciate eyes on https://review.openstack.org/#/c/100023/17 it reflects what we talked about in SAT
18:53:12 <topol> love BOC
18:53:13 <morganfainberg> henrynash, s/your/yoür
18:53:50 <morganfainberg> ok i'll update the spec to reflect the discussion here.
18:53:50 <dolphm> morganfainberg: fwiw, freenode won't let me /nick to dölphm
18:54:02 <morganfainberg> dolphm, WHAT?! lammmme
18:54:09 <dolphm> "Erroneous Nickname"
18:54:12 <topol> freenode keeping folks in line
18:54:15 <bknudson> it must be taken already
18:54:20 <hrybacki> so many upset Germans
18:54:37 <morganfainberg> /nick mörganfaïnbërg
18:54:37 <stevemar> hrybacki, not after sunday's win
18:54:38 <dolphm> so, 5 minutes:
18:54:47 <dolphm> #topic open discussion
18:54:47 <topol> They are HAPPY!
18:54:55 <dolphm> and holy crap that was the longest agenda we've ever made it through
18:55:01 <hrybacki> stevemar: solid point :P
18:55:08 <stevemar> dolphm, good leaderizing
18:55:16 <morganfainberg> also yay for hrybacki making it to the meetup!!
18:55:18 <bknudson> kept it on topic somehow
18:55:21 <lbragstad> ++
18:55:22 <stevemar> we managed to save all our jokes for the end
18:55:36 <hrybacki> thanks all, it was honestly amazing learning from y'all in person
18:55:48 <dolphm> morganfainberg: hrybacki: ++
18:56:14 <topol> defintely a productive time
18:56:23 <jamielennox> dolphm: are you looking at a client release any time soon?
18:56:35 <dolphm> jamielennox: YES! i wanted to poke you about that
18:56:44 <dstanek> so it looks like we have 47k lines of code
18:56:48 <dolphm> barbican wants a release soon to take advantage of your owrk
18:56:55 <dolphm> jamielennox: any blockers to doing that today?
18:57:04 <dolphm> (0.10.0?)
18:57:10 <bknudson> dstanek: does that include oslo-incubator?
18:57:19 <dstanek> bknudson: yes
18:57:20 <bknudson> because hopefully that will be going away mostly
18:57:23 <dolphm> dstanek: in keystone?
18:57:31 <stevemar> dolphm, can we wait until mareks stuff is in? it's gating now
18:57:31 <jamielennox> dolphm: let me have a quick look through, but i think most of what i have left is a nice-to-have for this release
18:57:40 <dolphm> stevemar: sure, give me patch numbers
18:57:52 <dstanek> ~45k without
18:57:53 <stevemar> dolphm, also everything is blocked because of bug 1342262
18:57:55 <uvirtbot> Launchpad bug 1342262 in openstack-ci "virtualenv>=1.9.1 not found for py26 environments" [Undecided,In progress] https://launchpad.net/bugs/1342262
18:58:11 <dolphm> stevemar: ah yeah
18:58:14 <dolphm> alright
18:58:17 <topol> I thought dolphm charged a beer to release a new client. Guess the price has dropped
18:58:35 <stevemar> dolphm, https://review.openstack.org/#/c/92166/ i would like that one in
18:59:00 <marekd> stevemar: ++++++++++++++++++++++++++++
18:59:02 <dolphm> ooooh raise ReleaseNotFunded(_('Beer required', lang=oslo.i18n.en_AU))
18:59:27 <topol> type=imported
18:59:30 <stevemar> dolphm, can you release a new version if the gate is failing?
18:59:48 <dolphm> stevemar: marekd: but there's also https://review.openstack.org/#/c/99704/
18:59:59 <stevemar> dolphm, do you just take a snap shot of the current master level and thats it?
19:00:21 <dolphm> stevemar: tag and upload the tag; but i wouldn't want to release with a jammed gate anyway
19:00:23 <dolphm> time!
19:00:26 <dolphm> #endmeeting