Monday, 2019-07-29

*** tetsuro has joined #openstack-placement02:01
*** tetsuro has quit IRC03:37
*** tetsuro has joined #openstack-placement04:06
*** tetsuro has quit IRC05:30
*** e0ne has joined #openstack-placement05:41
*** takashin has quit IRC06:04
*** e0ne has quit IRC06:11
*** tetsuro has joined #openstack-placement06:38
*** ttsiouts has joined #openstack-placement06:56
*** tssurya has joined #openstack-placement07:14
*** tetsuro has quit IRC07:17
*** ttsiouts has quit IRC07:25
*** tetsuro has joined #openstack-placement07:45
*** tetsuro has quit IRC07:50
*** ttsiouts has joined #openstack-placement07:57
*** tetsuro has joined #openstack-placement08:43
*** tetsuro has quit IRC08:47
*** e0ne has joined #openstack-placement09:08
*** altlogbot_2 has quit IRC09:24
*** altlogbot_2 has joined #openstack-placement09:25
*** takashin has joined #openstack-placement09:34
*** takashin has left #openstack-placement09:36
*** cdent has joined #openstack-placement09:37
*** cdent has quit IRC10:41
*** jaypipes has joined #openstack-placement11:26
*** cdent has joined #openstack-placement11:46
*** artom has joined #openstack-placement12:20
*** mriedem has joined #openstack-placement12:47
*** cdent has quit IRC12:47
*** jroll has quit IRC13:07
*** jroll has joined #openstack-placement13:08
*** cdent has joined #openstack-placement13:14
*** cdent has quit IRC13:23
*** cdent has joined #openstack-placement13:48
efriedcdent: Going to propose a new os-traits release (unless you already did that)13:50
cdenti have not, please go ahead13:52
efriedcdent: https://review.opendev.org/67329413:52
*** artom has quit IRC13:54
*** dklyle has quit IRC14:00
*** dklyle has joined #openstack-placement14:00
*** tetsuro has joined #openstack-placement14:20
efriedtetsuro: you blew my freaking mind, again.14:23
efried(apologies for the idiom - this is a good thing)14:24
*** tetsuro has quit IRC14:24
efriedcdent: any idea where it's documented that "smaller dict compares smaller"?14:25
cdentefried: I was just reading/thinking about that and don't have anything (yet)14:26
efriedIt turns out to be a really hard thing to google for.14:27
efriedaccording to this, it's consistent but undefined: https://docs.python.org/2.3/ref/comparisons.html14:28
cdentefried: well I don't think what you think is happening is happening14:29
cdentbecause in python3 your example is TypeError14:29
efriedwhich example?14:29
cdentd1 > d214:29
efriedmm14:30
efriedso then14:30
cdentso something else than what you think is being sorted, I reckon14:30
cdenttetsuro was saying it should be the keys14:30
cdentwhich is the rp uuids14:30
cdentbut even then, it's not clear14:31
efriedI get the same TypeError for sorted([d1, d2])14:31
cdentyes, you would14:31
cdentwhich is why it is something else14:31
efriedso let me try his solution in py3 for the gabbi...14:31
cdentmy guess is that /allocations is returning/operating something to the parser/processor that is not immediately obvious14:32
efriedcause if it works, it means gabbi (or jsonpath?) is overriding that sort impl somehow.14:32
cdentI think it is more likely the case that we're not interpreting /allocations correctly14:32
efriedah, nope, py3 gives that same TypeError.14:32
cdentit's not gabbi14:32
cdentit's jsonpath14:32
cdentso is perhaps the answer to "I assume you tried it?" is "no"?14:33
efriedor tried it in py2, where it *does* work.14:34
efriedat least it worked for me.14:34
efriedAnd I would say it was sorting on rp UUIDs and I just got lucky, except the isolated test where I used 'zzz' and 'aaa','bbb'14:34
efriedIt could also be sorting on like __id__ or something14:35
efriedand again just getting luckiy.14:35
efriedlucky14:35
efriedbut the fact that it explodes in py3 makes it a no go anyway.14:35
cdentthat either of you are testing py2 is _huge_ bug14:35
cdentforget about py214:35
*** ttsiouts has quit IRC14:35
cdentits only for the gate and distros. it is not our concern14:35
*** ttsiouts has joined #openstack-placement14:36
*** ttsiouts has quit IRC14:40
*** ttsiouts has joined #openstack-placement14:41
*** jaypipes has quit IRC14:46
*** belmoreira has joined #openstack-placement14:51
openstackgerritEric Fried proposed openstack/placement master: Extra gabbi tests for same_subtree  https://review.opendev.org/66993015:09
*** artom has joined #openstack-placement15:20
*** ttsiouts has quit IRC15:23
*** ttsiouts has joined #openstack-placement15:24
*** tssurya has quit IRC15:26
*** ttsiouts has quit IRC15:29
*** e0ne has quit IRC15:30
efriedcdent: Moving the logger "in the way you think you're moving it"15:34
efriedcdent: ==> "...until it works"15:35
efriedwhich is why I need your help to make it also be "...and makes sense"15:35
efriedbecause middleware is a big mystery to me.15:35
cdentwas my explanation (made before I had enough coffee) insufficiently clear to suss a next step?15:36
efriedUpon first reading, very unclear, but I'm 99% sure that's due to my ignorance and lack of context, not your explanation.15:36
cdenthow can I help?15:36
* efried reads a couple more times15:37
cdentit's not a one way stack, they are wrappers15:37
cdentthat have code on both sides of the "wrap"15:37
efriedoy15:42
efriedit's not clear from the comment in the code which thingy is being referred to as "microversion middleware"15:43
efriedbut yeah, in any case it appears as though the comment is out of date wrt the req_id_middleware.15:43
cdentthe comment is out of date because the microversion middlware is now above the comment15:45
cdent$the_stack(middleware(handler.py))15:45
efriedoh, look, there it is.15:45
efriedIs it called the same way on both sides of the application?15:46
efried"it" being the things in that list15:46
efriedso if the list is [a,b,c] what I'm understanding is we call15:48
efriedc(), b(), a(), application(), a(), b(), c()15:48
efriedright?15:48
efriedbut are those calls all just __call__? Or, it kinda looks like it might be the responsibility of __call__ to set up whatever the call winds up being on the post-side15:50
efriedand some of them don't do that, so they in fact only get called on the pre-side?15:50
cdentsorry efried, I'm in several conversations at once15:55
cdentbut yes, that interpretation is correcty15:56
cdentif no 'replacement_start_response' is defined, then they generally only operate on the "in" side15:56
cdent(what you're calling pre)15:56
efriedcdent: I got it sussed15:57
efriedbased on this: https://opendev.org/openstack/placement/src/branch/master/placement/tests/unit/test_requestlog.py#L34-L3515:57
efried...it's just a hole in the test fixture being used15:58
efriedadded that same thing to the failing test and it works.15:58
openstackgerritEric Fried proposed openstack/placement master: Do request_log middleware last  https://review.opendev.org/67302715:59
efriedcdent: ^16:00
cdentright, that's what I was trying to say when I pointed to blank's signature when leaving my comment16:00
cdentwill look in a sec, I'm trying to dredge my memory for why I ordered things as I did, all those years ago16:00
cdentbecause there were reasons16:00
cdentbut some of it may have been as useless as "don't mix your ugly nova shit in my cookies"16:01
cdentso probably time to re-evaluate16:01
efriedcdent: Your explanation now makes a lot more sense.16:01
efriedremember a week or two ago when I said some people learn by reading things and some by looking at examples.16:01
efriedTotally what happened here.16:01
* cdent nods16:02
cdentI tend to forget that "knowing wsgi" is not a required thing in the openstack community16:02
*** belmoreira has quit IRC16:05
efriedI would expect that "knowing X" is not a required thing in the openstack community for all X except, like, git/gerrit16:05
efriedEven python isn't necessary for some projects16:05
* cdent sighs16:06
efriedthe thing that supposedly makes it work is that no one person needs to know all the things, as long as *somebody* (preferably more than one somebody, in case lottery/bus) knows each thing.16:06
efriedbecause the whole is greater than the sum of the parts and all that.16:06
* cdent knows all this16:06
cdentI wasn't commenting that people _should_ know wsgi16:06
cdentjust that I forget16:06
efriedlooks like it *might* be oslo.middleware that's adding REMOTE_ADDR16:09
efriednone of the other thingies appear to reference it.16:09
cdentthat might be a bug, not really sure16:09
efriedI updated the patch in a way that I reckon makes sense anyway, so I reckon we can just move on.16:11
efriedThe thing works in real life, and adding that env var to the blank thingy has precedent from the other test, so...16:12
cdentyeah, it's not a bug in placement, but might be a bug in the oslo stuff16:13
efriedunrelated note, it looks like test_deploy.py and test_requestlog.py could probably be combined16:13
cdentcould be16:14
cdentthey were probably created as a "test this file", "test this other file"16:14
cdentwhich for unit files at least, makes sense16:14
cdents/files/tests/16:14
cdenti'm super duper allergic today16:14
cdentso not very smart16:14
efriedI'm not going to take the time to do it right now. Bigger fish.16:16
efriedbut now I've mentioned it.16:16
cdentefried: so16:21
cdentif we put request_log after request_id_middleware, then the debug message in request_log (on the way in) will not have the request id, only the info long (on the way out)16:22
cdentit should probably be request_id, requrest_log, everything else16:22
cdentefried: since I'm in there, I will fix it, cool?16:24
efriedmeaning request_id last in the list, so it happens first on the way in, and then request_log will pick it up in both directions?16:25
cdentyes16:25
efriedthat makes sense to me (now)16:26
efriedcdent: should I just reswizzle my patch?16:26
cdenti already have something based off yours16:26
cdentso will push them both up16:26
efriedsince it's essentially going to be nullified by yours?16:26
efriedokay, shrug16:26
cdent(this computer is so slow)16:31
openstackgerritChris Dent proposed openstack/placement master: Do request_log middleware next to last  https://review.opendev.org/67302716:35
openstackgerritChris Dent proposed openstack/placement master: Clarify the NOTE associated with ordering of middleware  https://review.opendev.org/67333516:35
cdenthmm, I suppose I've confused the summary line now16:36
*** N3l1x has joined #openstack-placement16:43
efriedcdent: perhaps the point is now "do request_id first"16:50
efriedalthough "do logging last so it gets the closest thing to the real payload" is also the point16:51
efriedbut the both-sides-of-the-application thing makes first/last kind of a bendy concept16:51
efriednot so for reqid, which doesn't have an "after".16:52
efriedBut for req log it's all or nothing.16:52
efriedit's almost like we should have two req log middlewares: on for the way in, which is done "last" (so first in the list) and another for the way out, which is also done "last" (so first on the list, but a no-op on the way in).16:52
efriedsee, now I understand this thing juuuust enough to be really dangerous.16:53
efriedsorry, that last 'first' should have been 'last'16:54
efriededit: it's almost like we should have two req log middlewares: on for the way in, which is done "last" (so first in the list) and another for the way out, which is also done "last" (so *last* on the list, but a no-op on the way in).16:54
cdentat some point you have to accept that you middlware is middlware and that it works16:56
cdenteven without the e16:56
cdentI reckon that my typing/spelling will improve at least 50% when I'm able to get rid of this macbook pro16:57
cdentanyway, I'm going to soak my head16:57
* cdent waves16:57
*** cdent has quit IRC16:57
*** e0ne has joined #openstack-placement17:14
*** artom has quit IRC17:14
*** e0ne has quit IRC17:20
*** artom has joined #openstack-placement17:44
*** e0ne has joined #openstack-placement19:22
*** belmoreira has joined #openstack-placement20:09
*** e0ne has quit IRC20:46
*** belmoreira has quit IRC21:17
*** tetsuro has joined #openstack-placement21:45
*** artom has quit IRC21:54
*** mriedem has quit IRC22:11
*** tetsuro has quit IRC22:49

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!