Sunday, 2014-03-16

*** leseb has quit IRC01:33
*** stevemar has quit IRC01:36
*** morganfainberg is now known as morganfainberg_Z01:42
*** topol has joined #openstack-keystone01:42
*** morganfainberg_Z is now known as morganfainberg01:52
*** david-lyle has quit IRC02:00
*** mberlin has quit IRC02:03
*** mberlin has joined #openstack-keystone02:20
*** dstanek has quit IRC02:32
*** topol has quit IRC02:35
*** thedodd has joined #openstack-keystone02:37
ayoung-zzzmorganfainberg, are you actually there?02:45
morganfainbergayoung-zzz, sorta02:45
ayoung-zzzmorganfainberg, what does this line of code do?02:47
ayoung-zzz link in a sec02:47
ayoung-zzznote that subnode is the collection in the for statement above02:47
ayoung-zzzI thought I understood this code, but YorikSar did something beyond my Ken02:48
ayoung-zzzmorganfainberg, what does python do in an iteration if you change the variable that is used in a for statement?  I know that if you modify the underlying collection, you get an error02:48
morganfainbergok so the only place where you need to worry about oddities is when you're dealing with the actual iterator changing or assigning a value inside a separate scope02:49
morganfainbergfor loop isn't _actuall_ a separate scope02:49
morganfainbergso what you're doing is you're rebinding subnode to the current bundle, so that when you hit the else you have something to iterate over02:50
morganfainbergthat is assuming the bundle has changed.02:50
* morganfainberg personally really doesn't like for/else02:50
ayoung-zzzmorganfainberg, so it is "first match" semantics here?  If subnode gets reassigned, restart the looping?  And the origianal loop never gets finished>02:50
morganfainbergin this case, you could remove the else and back-dent the second for loop and it would probably be easier to read02:51
morganfainbergoooh wait a sec02:51
morganfainbergi was reading the outer loop02:51
morganfainberghold on here02:51
ayoung-zzzI liked it better when it was recursive, but I think I got caught up in the elegance of this rewrite02:51
morganfainbergok, i _think_ the original for isn't impacted by the later rebind02:52
morganfainbergbecause the iterator has already been created02:52
ayoung-zzzthe origianl for is on NAMEs02:52
morganfainbergline 18102:52
morganfainbergif you were to change the contents of "subnode" that would be a problem02:52
morganfainbergin this case we're changing the reference of what subnode is.02:53
ayoung-zzzthis is icky02:53
ayoung-zzzrequires way to much deep python know-how to follow the logic02:53
ayoung-zzzlike the filter statment on 19002:53
morganfainbergoh wow. yeah you're changing the loop mid-run02:54
morganfainbergoh man.02:54
morganfainbergbut you're not changng the references02:54
morganfainbergok here this explains it better02:54
ayoung-zzzthe problem is that the code seems to be failing once I move it to the client.  I suspect it has something to do with marshalling the events themselves and building the tree with the reconstitued events02:55
ayoung-zzzbut this is failing
ayoung-zzzand I can't understand the code02:57
*** zhiyan_ is now known as zhiyan02:57
ayoung-zzzmorganfainberg, anyway, waiting on your explanation, but I think we need to make this code more readable.02:57
morganfainbergayoung-zzz, so the iteration never changes (the loop on 181) but each time you run through the iteration, you're potentially changing the value of subnode for when you hit else02:58
morganfainbergthe else is hit if there isn't an explicit break in the for loop (in this case the return isn't called)02:58
ayoung-zzzpotentially....which is way too subtle02:58
morganfainbergthis becomes a lot easier to read if you remove the else and back-dent that subnode for loop02:59
*** zhiyan is now known as zhiyan_02:59
morganfainbergayoung-zzz, sure the changing of the value is a bit odd, but i think what makes it hard to grasp is both that plus for/else02:59
morganfainbergfor / else should (imo) always be a call to another method, and never done03:00
morganfainbergi just don't like reading it, nor will most python developers feel it makes it easier to read03:00
*** mberlin1 has joined #openstack-keystone03:01
ayoung-zzzthat code is supposed to be leaf node logic03:01
morganfainbergwell it is03:01
ayoung-zzztest still fails...but no surprise there03:01
morganfainbergit's just hard to grok03:02
morganfainbergand i agree it should be more readable03:02
ayoung-zzzI copied the code from server to client....I don;t like that it fails, and I really don't like how hard it is to follow03:02
ayoung-zzzI think I want to clean up the server code before dragging it on over.03:02
morganfainbergheck, just using a variable not called "subnode" that bundle is assigned to would make it easier to read03:03
ayoung-zzzOK.. that can happend later, not going to hjappend to night03:03
*** mberlin has quit IRC03:03
ayoung-zzzbundle is also a bad name.  He origianlly used "faggot"  as, I am guessing, he is not a native english speaker03:03
morganfainbergoh dear03:03
ayoung-zzztechnically, it was a correct use of the word, but in its origianl meaning which is long since forgotten03:04
ayoung-zzzkinda like fascii03:04
ayoung-zzzlet me see what happens if I change the logic on the server to look like what you suggest...03:04
morganfainberg2 changes i recommend, 1: remove the for/else and backdent03:05
morganfainberg2: don't reuse "subnode" in the "leaf" loop03:05
ayoung-zzztests still pass with it03:06
morganfainbergi think recursive might have been easier to read :P03:10
ayoung-zzzyeah.  I might move back to that03:10
morganfainbergso this imo is way easier to read: still not 100% clear, but a comment will cover that03:11
morganfainbergand this is probably the best (still needs comments) without going back to recursion03:13
ayoung-zzzmorganfainberg, that subnode=bundle must be more significant03:13
morganfainbergoh ohhhh03:13
morganfainbergactually it is03:13
morganfainbergoutter loop03:13
morganfainbergit affects subsequent runs of the outerloop03:13
morganfainbergactually... i wonder if this could possibly be an issue.03:14
ayoung-zzzalmoste certainly03:14
morganfainbergit seems to me we are eliminating a ton of possible places to look in the revoke_map03:14
morganfainbergpotentially not checking revocations correctly03:14
ayoung-zzzso whatever subnode is set to in the last iteration through the loop is what will be iterated over the next go round03:15
ayoung-zzzno, I don;t think we miss anything03:15
ayoung-zzzthat is why it was added to the bundle03:15
morganfainbergoh i see03:16
ayoung-zzzbundle gets filtered, but not reset03:16
morganfainbergkeeps adding to it.03:16
morganfainbergso you end up with the data from all the _NAMES by the end03:16
ayoung-zzzyeah, and the else block only gets executed once there is nothing left in bundle03:16
ayoung-zzzthe filter removes any internal nodes that don't have leaf nodes03:17
morganfainbergstill can remove the else and backdent w/o issue03:17
morganfainbergcan't stop the re-use of subnode though03:17
ayoung-zzzIt changes the logic03:18
morganfainbergno it doesn't03:18
ayoung-zzzif you remove, that code gets executed more03:18
morganfainbergbackdenting wouldn't change anything03:18
ayoung-zzzI think the else is a performance tune03:18
ayoung-zzzyeah,  in his version, it only gets executed if subnode is empty03:18
ayoung-zzzin yours it gets executed each time trhough the NAMES loop03:19
ayoung-zzzit just never matches03:19
morganfainbergno it gets executed in either case03:19
ayoung-zzzits only an empty eva of the for loop that gets executed, so no big hit to remove03:19
morganfainbergunless bundle is legitimately empty after the filter, which case the return03:19
morganfainbergthe else is run after the for loop continues, but if you had a break, the else wouldn't run03:20
morganfainbergin this case the break is a return, so the whole function is exited,03:20
morganfainbergthe backdent wouldn't matter03:20
ayoung-zzzwow, I misunderstood that03:20
morganfainbergfor/else is not straightforward at all03:20
morganfainbergand it doesn't make intuitive sense03:21
ayoung-zzzrecursive would be much clearer.  I think I'll bring back the old code.03:21
morganfainbergi'm also not sure that there is a performance win to not just building the tree and then doing the leaf for loop03:21
morganfainbergit seems like we're doing worst case O(2n) vs a guaranteed o(n+1)03:22
ayoung-zzznow, he took the key  thing from me, and I am not certain it makes sense,,  the key being user='asikjdhflkjasd'03:22
morganfainbergi might be wrong though.03:22
ayoung-zzzor user='*'03:22
ayoung-zzzOK...gonna crash.  This can wait03:23
*** ayoung-zzz is now known as ayoung-zzzZZ03:23
morganfainbergplenty of time to discuss it03:23
morganfainbergnight dude03:23
*** kfox1111 has joined #openstack-keystone04:10
*** kfox1111 has quit IRC04:22
*** thedodd has quit IRC04:25
*** dims has quit IRC04:59
*** dims has joined #openstack-keystone05:00
*** chandan_kumar has joined #openstack-keystone05:14
openstackgerritJenkins proposed a change to openstack/keystone: Imported Translations from Transifex
*** chandan_kumar has quit IRC06:34
*** dstanek has joined #openstack-keystone06:49
openstackgerritClint "SpamapS" Byrum proposed a change to openstack/keystone: Discourage use of pki_setup
*** flaper87|afk is now known as flaper8709:17
*** dstanek has quit IRC09:20
*** henrynash has joined #openstack-keystone10:28
*** morganfainberg is now known as morganfainberg_Z11:12
*** henrynash has quit IRC11:29
*** henrynash has joined #openstack-keystone11:34
openstackgerritClint "SpamapS" Byrum proposed a change to openstack/keystone: Discourage use of pki_setup
*** dims has quit IRC12:40
*** dims has joined #openstack-keystone12:45
*** lcostantino has joined #openstack-keystone13:20
*** lcostantino has quit IRC13:39
*** henrynash has quit IRC13:39
*** henrynash has joined #openstack-keystone13:42
*** henrynash has quit IRC13:48
*** zhiyan_ is now known as zhiyan15:39
*** thedodd has joined #openstack-keystone15:42
*** zhiyan is now known as zhiyan_15:46
*** thedodd has quit IRC16:41
*** wchrisj has joined #openstack-keystone17:09
*** pete5 has joined #openstack-keystone17:30
*** wchrisj has quit IRC17:39
jogomorganfainberg_Z: thanks stable/havana is working again20:01
*** henrynash has joined #openstack-keystone20:41
*** leseb has joined #openstack-keystone20:46
*** bvandenh has quit IRC21:19
*** bvandenh has joined #openstack-keystone21:21
*** leseb has quit IRC22:03
*** thiagop_ has quit IRC22:43
*** harlowja_away has quit IRC22:43
*** zhiyan_ has quit IRC22:43
*** Daviey has quit IRC22:43
*** YorikSar has quit IRC22:43
*** sudorandom has quit IRC22:43
*** marekd|away has quit IRC22:43
*** bknudson has quit IRC22:43
*** chmouel has quit IRC22:43
*** bvandenh has quit IRC22:43
*** pete5 has quit IRC22:43
*** dolphm has quit IRC22:43
*** lbragstad has quit IRC22:43
*** haneef_ has quit IRC22:43
*** henrynash has quit IRC22:43
*** dims has quit IRC22:43
*** jimbaker has quit IRC22:43
*** dvorak has quit IRC22:43
*** mberlin1 has quit IRC22:43
*** openstackgerrit has quit IRC22:43
*** jaypipes has quit IRC22:43
*** jamielennox|away has quit IRC22:43
*** flaper87 has quit IRC22:43
*** koolhead17 has quit IRC22:43
*** jraim has quit IRC22:43
*** jogo has quit IRC22:43
*** dtroyer has quit IRC22:43
*** jordant has quit IRC22:43
*** zigo has quit IRC22:43
*** mhu has quit IRC22:43
*** mfisch has quit IRC22:43
*** ChanServ has quit IRC22:43
*** morganfainberg_Z has quit IRC22:43
*** vhoward has quit IRC22:43
*** huats has quit IRC22:43
*** ayoung-zzzZZ has quit IRC22:43
*** anteaya has quit IRC22:43
*** luisbg has quit IRC22:43
*** bvandenh has joined #openstack-keystone22:45
*** henrynash has joined #openstack-keystone22:45
*** pete5 has joined #openstack-keystone22:45
*** dims has joined #openstack-keystone22:45
*** mberlin1 has joined #openstack-keystone22:45
*** openstackgerrit has joined #openstack-keystone22:45
*** jraim has joined #openstack-keystone22:45
*** zhiyan_ has joined #openstack-keystone22:45
*** harlowja_away has joined #openstack-keystone22:45
*** vhoward has joined #openstack-keystone22:45
*** jogo has joined #openstack-keystone22:45
*** dolphm has joined #openstack-keystone22:45
*** Daviey has joined #openstack-keystone22:45
*** YorikSar has joined #openstack-keystone22:45
*** sudorandom has joined #openstack-keystone22:45
*** jimbaker has joined #openstack-keystone22:45
*** dvorak has joined #openstack-keystone22:45
*** marekd|away has joined #openstack-keystone22:45
*** lbragstad has joined #openstack-keystone22:45
*** haneef_ has joined #openstack-keystone22:45
*** flaper87 has joined #openstack-keystone22:45
*** bknudson has joined #openstack-keystone22:45
*** jordant has joined #openstack-keystone22:45
*** zigo has joined #openstack-keystone22:45
*** huats has joined #openstack-keystone22:45
*** mhu has joined #openstack-keystone22:45
*** ayoung-zzzZZ has joined #openstack-keystone22:45
*** chmouel has joined #openstack-keystone22:45
*** mfisch has joined #openstack-keystone22:45
*** jaypipes has joined #openstack-keystone22:45
*** jamielennox|away has joined #openstack-keystone22:45
*** koolhead17 has joined #openstack-keystone22:45
*** luisbg has joined #openstack-keystone22:45
*** anteaya has joined #openstack-keystone22:45
*** dtroyer has joined #openstack-keystone22:45
*** morganfainberg_Z has joined #openstack-keystone22:45
*** ChanServ has joined #openstack-keystone22:45
*** sets mode: +o ChanServ22:45
*** flaper87 is now known as flaper87|afk22:45
*** thiagop_ has joined #openstack-keystone22:56
*** leseb has joined #openstack-keystone23:14
*** jamielennox|away is now known as jamielennox23:16
*** leseb has quit IRC23:18
*** henrynash has quit IRC23:21

Generated by 2.14.0 by Marius Gedminas - find it at!