18:00:52 <dolphm> #startmeeting keystone
18:00:53 <openstack> Meeting started Tue May  7 18:00:52 2013 UTC.  The chair is dolphm. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:56 <openstack> The meeting name has been set to 'keystone'
18:01:01 <topol> Hello
18:01:45 <dolphm> #topic High priority bugs or immediate issues?
18:01:58 <dolphm> (other than stable/grizzly stuff, which is on the agenda for last)
18:02:02 <ayoung> dolphm, Well, the gate is now fixed
18:02:14 <dolphm> ayoung: bknudson: thanks! ^
18:02:20 <ayoung> IPv6 and the memcached fixes are in
18:02:31 <dolphm> ayoung: what was the memcache fix?
18:02:40 <ayoung> dolphm, dolphm blackout one version of it
18:02:45 <dolphm> oh the 1.51 thing
18:02:52 <ayoung> dolphm, the fix was done by putting a later version onto the mirrors
18:02:54 <bknudson> hi
18:04:16 <ayoung> dolphm, the only high bug I was aware of was the LDAP domain issue
18:04:32 <fabio> Anvil4Me~!
18:04:52 <simo> fabio: nice pw :)
18:04:55 <gyee> ha
18:05:04 <fabio> sorry wrong window :-)
18:05:08 <dolphm> ayoung: cool
18:05:18 <ayoung> dolphm, this one is the one we are going with, right? https://review.openstack.org/#/c/28197/
18:05:36 <dolphm> i'd like the ldappers to decide that
18:05:48 <dolphm> but that's on the agenda in a minute
18:05:54 <ayoung> cool
18:05:55 <dolphm> or we can just skip to it..
18:06:08 <dolphm> #topic stable/grizzly 2013.1.1 release and the default domain in LDAP
18:06:15 <dolphm> #link http://lists.openstack.org/pipermail/openstack-stable-maint/2013-May/000611.html
18:06:21 <dolphm> stable/grizzly is happening this week
18:06:36 <ayoung> #link https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Agenda_for_next_meeting
18:06:38 <dolphm> i asked that keystone 2013.1.1 be held until we get a default domain fix together for ldap
18:06:59 <dolphm> #link https://bugs.launchpad.net/keystone/+bug/1168726
18:07:01 <uvirtbot> Launchpad bug 1168726 in keystone/grizzly "default_domain_id breaks the ability to map keystone  to ldap" [Critical,In progress]
18:07:07 <ayoung> dolphm, I actually mentioned that to apevec as well
18:07:23 <dolphm> so, *a* fix needs to merge ASAP if we're going to do a backport of anything at all
18:07:46 <topol> dolphm, whats the review number
18:07:55 <ayoung> topol, gyee please look at https://review.openstack.org/#/c/28197/
18:07:55 <bknudson> I'll review it this afternoon.
18:07:58 <dolphm> and to re-iterate, my proposed solution is backporting a feature-cut (multi-domain support for ldap) https://review.openstack.org/#/c/28197/
18:08:05 <dolphm> #link https://review.openstack.org/#/c/28197/
18:08:09 <ayoung> dolphm, I endorce this approach
18:08:12 <ayoung> endorse
18:08:21 <topol> dolphm, I endorse as well
18:08:31 <dolphm> topol: sooner the better
18:08:31 <bknudson> I was able to work around it earlier, just added a domain entry
18:08:50 <topol> I will review right after this meeting
18:08:51 <ayoung> bknudson, yes, but it breaks other things that way
18:08:59 <dolphm> bknudson: yeah, jcannava confirmed you could work around it post-config as well
18:09:07 <ayoung> bknudson, if LDAP is read only, there is no field available for domain
18:09:22 <bknudson> I thought it was businessCategory
18:09:28 <gyee> :)
18:09:32 <topol> yes, but breaks our read only
18:09:58 <topol> bknudson, mixing two different things
18:10:29 <topol> its not the businessCategory mapping; its the need for a default domain or even horizon pukes
18:10:31 <ayoung> dolphm, yeah, I don't think your fix is going to be sufficient
18:10:49 <ayoung> we need to remove businessCategory and the domain field or we still have a broken LDAP
18:10:56 <ayoung> was it spzala 's fix that did that?
18:11:16 <dolphm> ayoung: explain?
18:11:27 <dolphm> ayoung: from config?
18:11:42 <ayoung> dolphm, no, the user and projects objects
18:11:46 <topol> Can't you put the domain mapping to businessCategory on the ignore list?
18:11:55 <dolphm> user_domain_id_attribute?
18:12:00 <topol> for groups, etc
18:12:03 <ayoung> dolphm, right
18:12:14 <bknudson> so every user in LDAP should be in the default domain
18:12:17 <ayoung> I thought I saw a patch that removed it
18:12:24 <ayoung> bknudson, for now, yes
18:12:36 <topol> ayoung, why cant that just be fixed via config?
18:12:42 <bknudson> looks like dolphm's patch does that.
18:13:06 <bknudson> e.g., get_user() calls self._set_default_domain() on it.
18:14:58 <bknudson> so if you were using businessCategory for your domain id, it'd get wiped out.
18:15:07 <ayoung> bknudson, yes
18:15:18 <dolphm> wiped out or ignored?
18:15:58 <bknudson> _set_default_domain is going to overwrite whatever domain_id is in the ref and replace it with the default domain_id.
18:16:42 <topol> bknudosn, but what happens with user_domain_id_attribute?
18:17:01 <bknudson> I don't see user_domain_id being wiped out
18:17:08 <dolphm> bknudson: that's how the function behaves, but i don't think it will be overriding anything in the real world?
18:17:10 <topol> exactly
18:17:13 <ayoung> topol, OK,  I think you are right.  We cannot safely remove it. We need to set attribute_ignore on it
18:17:34 <topol> ayoung. yes, exactly
18:17:58 <topol> and that can be done via config
18:18:14 <bknudson> if domain_id attribute is ignored, does Keystone set user_domain_id to the default domain_id?
18:18:42 <ayoung> topol, so dolphm's patch should probably check for that value instead of blanket removing the domain.
18:18:47 <topol> in ldap in wont set it at all
18:19:08 * ayoung not happy with domain_attribute, but oh well
18:19:10 <bknudson> how is a client going to know what the default domain id is?
18:19:11 <dolphm> hmm, i need to update docstrings
18:20:05 <dolphm> erm, so create_user, for example, should be validating that the default domain was specified, and then remove the domain_id attribute before handing off to ldap
18:20:11 <dolphm> i'm not doing that second part atm
18:20:36 <ayoung> dolphm, it can be done another way
18:20:47 <ayoung> there is a field called attrbute_ignore.
18:20:49 <ayoung> I'll link
18:20:54 <dolphm> ayoung: why not fix it now?
18:21:01 <topol> thats in the config
18:21:21 <bknudson> I'd think you want to send the domain_id, and let ldap ignore it or not.
18:21:25 <topol> and thats how we handle attributes that may or may not map to ldap depending on the schema
18:21:33 <ayoung> https://github.com/openstack/keystone/blob/master/keystone/common/ldap/core.py#L251
18:21:38 <dolphm> if you've already deployed against ldap/ad with a real domain object, you shouldn't have to change config to use 2013.1.1
18:21:39 <topol> bknudson, AGREED!
18:21:58 <dolphm> if that's the case, then this is unbackportable
18:22:06 <ayoung> dolphm, what if some grizzly early adopter started using LDAP with domains
18:22:23 <topol> dolphm, two cases, one they let the domain map two busiensscategory or their equivalent or they use ignore
18:22:26 <dolphm> ayoung: that's the case i'm referring to which i'd like to handle gracefully
18:23:03 <topol> if you keep the ability to map to businesscatgory or equivalent you shouldnt break anyone
18:23:25 <topol> and then others can use the attribute ignore if they have readonly and it doesnt map
18:23:35 <bknudson> and don't wipe out the domain_id if LDAP returns it.
18:23:38 <dolphm> topol: two users: one has already deployed keystone 2013.1 against ldap/ad and created a domain object, and the other is on folsom, both are migrating to 2013.1.1
18:24:10 <dolphm> and read-only users are currently stuck on folsom
18:24:16 <ayoung> dolphm, so if default_domain is set, and 'user_attribute_ignore' is set...
18:24:29 <dolphm> dosaboy: default_domain what?
18:24:50 <topol> so you create a default domain, correct?
18:24:58 <bknudson> it's not created, it's virtual
18:25:06 <topol> that has an id attribute, correct?
18:25:30 <bknudson> the virtual domain has it's id set to the default_domain_id
18:26:00 <topol> K, so worst case that value gets shoved into businessCategory or equivalent (if they mapped it)
18:26:27 <topol> or they can choose to add to the ignore list for a read only ldap with no domain equivalent
18:26:34 <bknudson> I think that's what you'd want. If they ignored it then it doesn't go anywhere.
18:26:42 <topol> make sense?
18:26:53 <bknudson> so this patch seems to be doing "too much"
18:27:13 <topol> and we dont end up taking away the businessCategory mapping if someone is already using it
18:28:41 <ayoung> topol, it needs to be added to the ignore list for all objects
18:28:55 <ayoung> user, group, project at least...
18:29:02 <bknudson> ayoung: you mean by default?
18:29:32 <dolphm> i'm still lost on why we shouldn't just be stripping the domain_id attribute from all refs on create()
18:29:57 <topol> dolphm, you were scared someone was using it. you will break them
18:30:13 <ayoung> every single one of the assignments, too
18:30:30 <topol> or you can take it away and see if anyone screams...
18:30:53 <ayoung> bknudson, yes, by default
18:31:22 <ayoung> bknudson, one of the probles is that we don't have an upgrade script for LDAP, so we have no way of knowing.
18:31:35 <bknudson> ayoung: that sounds like a better solution to me.
18:31:37 <ayoung> So it needs to be well documented
18:31:53 <ayoung> bknudson, we need a read only default domain as well, I think
18:32:05 <ayoung> and I don;'t know what will happen if we just attribute ignore it
18:32:15 <bknudson> I like the read-only default domain.
18:32:20 <ayoung> can the daomin field be blank?
18:32:23 <ayoung> I suspect not
18:32:28 <dolphm> ayoung: where?
18:32:29 <topol> should we just pull it now and hope no one became dependent on it?
18:32:30 <ayoung> topol, have you tested this?
18:32:59 <topol> I have not tested dolphms patch and not tested making it ignore
18:33:03 <ayoung> topol, if you are going to suggest that we "just" do the attribute ignore, you need to, at a minimum, confirm it works.  I don;t think it will
18:33:06 <dolphm> topol: not if we can't handle it gracefully, but i don't understand why we would be breaking them by ignoring it (unless they've already deployed multi-domain, you mean?)
18:33:28 <topol> dolphm, that was the fear. Im not sure its realistic
18:34:09 <ayoung> dolphm, of the two cases, I think breaking LDAP for 99% of the users is a worse sin than breaking the early adopter that is using LDA domains
18:34:09 <dolphm> we need to ping the operators list on this
18:34:19 <ayoung> but we a damned either way
18:34:21 <topol> I rather do death or glory, pull it completely out and feel comfortable we know the code is solid.
18:34:37 <topol> ayoung, I agree
18:34:44 <dolphm> ayoung: unfortunately i agree
18:35:01 <dolphm> ayoung: that's a good way to word it, i might steal that
18:35:25 <topol> cause frankly its the direction we are heading one domain per ldap so we break them now or break them later when they really are dependent on it
18:35:31 <bknudson> The bug was reported by spzala... but I don't think that's because a customer complained.
18:35:41 <spzala> no
18:35:50 <topol> we found it doing a poc
18:35:56 <spzala> i found it via helping internal team
18:36:01 <ayoung> actually, I also reported it, as I found it broken when doing a basic LDAP install for the FreeIPA presentation
18:36:28 <bknudson> ok, just making sure that we had a good reason to backport to grizzly.
18:36:29 <ayoung> If we leave the domain attribute there, it needs to be completely ignorable
18:37:04 <topol> ayoung, what scary is the combinations we will have to debug if we leave it as an ignorable option or not...
18:37:17 <dolphm> ayoung: can you be more specific? "there" and "ignorable"
18:37:18 <ayoung> topol, agreed.  I am in favor of yanking it whole hog
18:37:20 <bknudson> isn't it already ignorable?
18:37:25 <ayoung> bknudson, I doubt it
18:37:36 <topol> we end up having to support two yucky options for a long time
18:37:36 <ayoung> bknudson, ignored just means not persisted to the DB
18:37:49 <topol> ie. not put into ldap
18:38:15 <ayoung> but if the code depends on that value, we have to do something nasty like populate it  from config if the LDAP server is not providing it.  HOrrible option
18:38:32 <ayoung> it needs to go
18:38:37 <topol> if we get shot either way I rather be shot by the .00001% that already depend on multiple domains for an ldap
18:38:42 <bknudson> we already do that for domain_id in identity v2.
18:38:45 <ayoung> I don;t think we have a choice
18:38:57 <ayoung> bknudson, will that work for V3?
18:38:59 <bknudson> This seems pretty similar
18:39:06 * ayoung doubts it, but would like someone to test
18:39:15 <topol> I agree with ayoung.  If we pull it now we have maybe one person yell at us
18:39:24 <ayoung> JOe Savak
18:39:32 <topol> We wait a year we could really get stuck
18:40:24 <simo> you should not hardcode LDAP queries, and just have defaults that can be changed and replacement variables
18:40:46 <simo> then a good default configuration taht defines the stuff the way you want it for default
18:40:56 <simo> look at postfix support for LDAP if you need inspiration
18:41:09 <topol> ayoung, problem with Joe is he hates us now a little or hates us later (when fully dependent on it) a ton
18:41:33 <ayoung> simo, agreed, but there are only limits to what we can do right now
18:41:52 <simo> ayoung: right now you need a sane if simpler code
18:42:04 <ayoung> the domain support was not well thought out in the context of LDAP, and needs to be rolled back.
18:42:14 <topol> big picture is we dont want to support multiple domains in a single ldap.   We either break the bad news to Joe now or later. But either way he will be upset
18:42:48 <simo> topol: I think you should not make that decision but for the short term it certainly is better to have less options than have broken ones
18:43:01 <bknudson> I'm sure Joe isn't impressed by how multiple domains is implemented today.
18:43:02 <ayoung> topol, eventually, we can do it via multiple subtrees, just not today
18:43:24 <ayoung> OK, dolphm what do we need to do to make this happen, besides rewrite the patch?
18:43:33 <topol> simo, problem is right now it really is broken. Need some time to do it right
18:43:47 <topol> ayoung, agreed
18:44:14 <ayoung> topol, are you going to complete the rewrite?
18:44:28 <dolphm> ayoung: i'm not sure i understand the changes i'd need to make, so i'd prefer someone else to volunteer to pick it up?
18:44:32 <ayoung> and by you, I mean spzala, of course
18:44:40 <topol> ayoung, rewrite of dolphs patch?
18:44:44 <dolphm> or i need a mean code review to get me going
18:44:52 <dwaite> my opinion - it would be better to have the default LDAP integration be as simple and maintainable as possible, even if that means additional functionality plugged in via contributed code
18:45:11 <ayoung> topol, either that or continue on with spzala 's but removing the domains attribute as well as making sure the domain API is not broken for LDAP
18:45:27 <topol> sahdev will help dolphm in any way he wants
18:45:45 <dolphm> i'm not sure why jsavak would care ahead of havana
18:45:47 <spzala> spzala: topol, yes
18:46:00 <ayoung> want to #action that?
18:46:16 <topol> sahdev likes dolphs approach
18:46:30 <dolphm> then there's no #action
18:46:32 <spzala> I like dolph's approach. as far as I know, domain support for ldap, wasn't complete....so for example, when you create user with domain_id attribute, there was no domain created and user was added to that domain.  So how would it break anything?
18:47:04 <ayoung> No
18:47:16 <ayoung> that is not sufficient
18:47:19 <ayoung> necessary yes
18:47:20 <gyee> like that, if it never works, then its not a bug :)
18:47:33 <ayoung> but we need to make sure that if the domain attribute remains, it can be ignored
18:47:33 <dolphm> ayoung: be careful about backportability
18:47:51 <dolphm> i'd like to just ignore it 100%
18:48:04 <bknudson> who decides backportability?
18:48:09 <ayoung> dolphm, someone needs to confirm it works.
18:48:11 <dolphm> stable maintenance team
18:48:14 <topol> dolphm, was your code on a path to ignore it?
18:48:15 <ayoung> I doubt that is the case
18:48:16 <bknudson> I've seen reviews in stable where they just say the change is too bit.
18:48:22 <bknudson> too big.
18:48:43 <dolphm> bknudson: +1
18:49:20 <bknudson> I think they would reject dolphm's patch, but I'm just guessing.
18:49:41 <ayoung> I think we have a broken impl, even with dolph's patch
18:49:48 <ayoung> suspect
18:49:57 <dolphm> bknudson: i wouldn't be surprised, but stakeholders need to beg either way
18:50:05 <bknudson> probably broken even without dolphm's patch, too.
18:50:13 <ayoung> I'll confirm
18:50:18 <dolphm> ayoung: can you propose a follow up fix?
18:50:23 <topol> sahdev's original pathc was much smaller
18:50:37 <bknudson> what was the original patch?
18:50:47 <topol> wasnt pretty but small and got the job done
18:50:53 <bknudson> is this the one to add domain with keystone-manage?
18:50:58 <spzala> topol: my patch was to return a default domain (virtual one) if one is not created
18:51:11 <ayoung> #link https://review.openstack.org/#/c/27364/
18:51:28 <spzala> ayoung: thanks
18:51:34 <bknudson> it failed jenkins so no one looked at it.
18:51:36 <ayoung> spzala, what does that do if there is no attribute available to map to the domain id?
18:52:51 <topol> bknudson, that was a jenkins bug I believe
18:52:58 <spzala> ayoung: the patch was on providing our conceptual domain
18:53:14 <spzala> bknudson: yes, that was due to 'token' bug
18:53:27 <spzala> that failed jenkins for many patches
18:53:38 <topol> what if sahdev ran his patch and did a fullr egression with domain_id_atrribute being ignored?
18:54:04 <dolphm> so, 8 minutes left... we need a strong consensus to backport anything here... if we don't have a consensus, i'd recommend that we leave stable/grizzly broken and think about how to move stable/folsom deployments to havana, or even publish a "fixed" driver outside of the openstack release cycle that those users can pick up
18:54:43 <ayoung> dolphm, I say to let spzala take it and run with it
18:55:00 <ayoung> and I will be involved on the approach
18:55:17 <spzala> ayoung: go with my patch? with ignore attribute?
18:55:51 <ayoung> spzala, yes plus you need to set the attribute to something that doesn exist.  busineesssCatagory might not even be there on the back end
18:56:22 <topol> ayoung doesnt exist is guarenteed to break. I dont understand
18:56:25 <ayoung> dolphm, we'll let you know shortly if this is going to work
18:56:41 <ayoung> topol, then we need to go further...lets just agree to work on it for now.
18:56:43 <spzala> ayoung: thanks. hmmm... I didn't get it either
18:56:56 <bknudson> I think we're at least headed to not backporting this for the stable/grizzly 2013.1.1
18:57:00 <dolphm> i'd also suggest considering splitting the ldap driver into drivers that serve more specific use cases, so serving one specific use case is much less likely to break others moving forward
18:57:06 <topol> ayoung, I just dont understand what you mean
18:57:35 <simo> dolphm: as part of https://wiki.openstack.org/wiki/MessageSecurity I need a key server and I am starting with building one in keystone, I have a couple of q.s about that, you think there is time ?
18:57:42 <ayoung> topol, that is fine, I can explain later...we have 3 minutes left in the meeting
18:57:43 <bknudson> a read-only LDAP driver would be nice.
18:57:45 <morganfainberg> dolphm: pluggable LDAP drivers?
18:58:16 <dolphm> simo: yes, i have an opinion... contribute to https://github.com/cloudkeep/barbican
18:58:19 <bknudson> morganfainberg: the LDAP driver is a plugin.
18:58:27 <simo> dolphm: unrelated
18:58:39 <morganfainberg> bknudson: oh right. ugh.  i came into this a bit late, brain is not 100%, sorry.
18:58:46 <morganfainberg> 100% firing yet*
18:58:49 <dolphm> morganfainberg: multiple ldap drivers
18:58:59 <morganfainberg> dolphm: right, makes sense.
18:59:04 <dolphm> like ldap.ReadOnlyDriver, etc
18:59:07 <ayoung> simo, dolphm lets move this discussion to #openstack-dev.  We are not going to finish it here and now
18:59:09 <topol> sahdev will investigate and will try fulll regression with domain_id_atrtribute ignored and will report back. patch will be small.  and then others folks call whether it meets backporting guidleines
18:59:09 <simo> dolphm: but if you feel strongly I can see
18:59:13 <dolphm> #endmeeting