Friday, 2019-07-26

*** artom has quit IRC03:27
openstackgerritHuachang Wang proposed openstack/os-traits master: CPU: add a trait for AVX512-VNNI support  https://review.opendev.org/67288807:02
*** ttsiouts has joined #openstack-placement08:03
*** tssurya has joined #openstack-placement08:08
*** tssurya has quit IRC08:23
*** cdent has joined #openstack-placement09:06
*** e0ne has joined #openstack-placement09:16
*** ttsiouts has quit IRC09:46
*** ttsiouts has joined #openstack-placement09:47
*** ttsiouts has quit IRC09:51
*** ttsiouts has joined #openstack-placement10:01
*** ttsiouts has quit IRC10:25
*** ttsiouts has joined #openstack-placement10:25
*** ttsiouts has quit IRC10:30
*** ttsiouts has joined #openstack-placement11:06
*** tssurya has joined #openstack-placement11:08
*** irclogbot_3 has quit IRC11:53
*** irclogbot_0 has joined #openstack-placement11:55
*** artom has joined #openstack-placement12:04
efriedcdent: heads up, once this is ready it'll need a non-Intel core to send it https://review.opendev.org/#/c/672888/12:13
cdentaye aye12:13
*** mriedem has joined #openstack-placement12:53
*** ttsiouts has quit IRC12:56
efriedcdent: I removed my -1 from --^13:05
cdentaye aye13:05
efriedIf you would care to render an opinion one way or the other13:05
cdentefried: will get to relative soon, in the midst of a thing13:05
efriedI would still prefer the underscore, but the evidence provided makes it less "mandatory"13:05
*** artom has quit IRC13:09
*** artom has joined #openstack-placement13:09
*** ttsiouts has joined #openstack-placement13:14
*** artom has quit IRC13:26
efriedcdent: off the top of your head, can request headers be got via environ['HEADERS']?13:54
cdentefried: it's not quite like that13:55
cdentyou've got two options13:55
efriedglad I asked13:55
cdentif all you have is an environ its environ['HTTP_UPPER_CASE_HEADER_NAME']13:55
cdentbut if you have something like a WebOb Request (req in placement) there 's req.headers which acts like a dict13:56
efriedactually, it looks like I have the headers where I need 'em. Thanks.13:56
cdentefried: what you are trying to do?13:56
efriedcdent: I noticed this:13:57
efriedhttps://opendev.org/openstack/nova/src/branch/master/nova/scheduler/client/report.py#L547-L55613:57
efriedand wondered why we would need to retrieve the x-openstack-request-id from the response, given that it should just be the same x-openstack-request-id (the global_request_id) we sent in in the first place.13:57
efriedBut I checked the logs and it ain't13:57
efriedhttp://logs.openstack.org/89/666889/11/check/nova-live-migration/917d052/logs/screen-n-cpu.txt.gz#_Jul_13_12_14_11_46196613:57
efriedThat req ID only shows up in that one line on the nova side, and for the one request on the placement side.13:57
efriedso I want to throw out some debug patches that dump the headers13:58
efried(btw, same behavior before and after cutting over to the global_request_id kwarg, in case you were wondering)13:58
cdentrequest id stuff has never seemed to work as advertised13:59
cdentwhich makes me think there's a concept gap somewhere13:59
efriedoy14:00
cdentwhich is one way of saying: i'm glad you are looking14:01
openstackgerritEric Fried proposed openstack/placement master: DNM: Where have all the global_request_id gone?  https://review.opendev.org/67298414:05
efriedI have a sneaking suspicion that "%s" % request.headers is going to give me something annoying like "<MultiValuedDict object at 0xaa0789a9b1c234c>"14:09
cdentgiven how easy it is to run the tests on the placement side, I would have thought you tested that locally first?14:11
efriedum14:13
efriedwhy you gotta be all reasonable and stuff?14:13
cdentit's a flaw, I've been working on it14:14
efriedhm14:15
efriedheaders: [('Content-Length', '162'), ('Content-Type', 'application/json'), ('openstack-api-version', 'placement 1.8'), ('vary', 'openstack-api-version')]14:17
efriedbut when I run with verbose=true I see this coming from... somewhere:14:17
efried< 404 Not Found14:17
efried< Content-Length: 16214:17
efried< Content-Type: application/json14:17
efried< openstack-api-version: placement 1.814:17
efried< vary: openstack-api-version14:17
efried< x-openstack-request-id: req-7f462322-0412-4c63-81aa-e55e8c7180bc14:17
cdentit's probably the order of the stack, lemme check something14:18
efriedwhen I set it up to fail the test, that same ID shows up in the errors list:14:18
efried      "errors": [14:18
efried        {14:18
efried          "status": 404,14:18
efried          "title": "Not Found",14:18
efried          "detail": "The resource could not be found.\n\n   ",14:18
efried          "request_id": "req-7f462322-0412-4c63-81aa-e55e8c7180bc"14:18
efried        }14:18
efried      ]14:18
efried(404 is the expected behavior btw)14:19
efriedback in 514:21
cdentyeah, I gotta change locations, will rejoin this in progress when I get to the new place14:21
*** cdent has quit IRC14:21
openstackgerritMerged openstack/os-traits master: CPU: add a trait for AVX512-VNNI support  https://review.opendev.org/67288814:22
*** artom has joined #openstack-placement14:26
*** cdent has joined #openstack-placement14:30
efriedThe more os-traits patches I see, the more I dislike the overengineered complexity of it all. We should have just had a straight up list of strings like we do for orc.14:42
efriedDo you happen to remember why it was done that way?14:42
efried(I may have asked this before)14:42
cdentefried: it's such a long time ago, I can't remember14:48
efrieddo you see any benefit today?14:48
cdentif I had to speculate it was something to do with being able to be in particular contexts and a generic love of namespaces14:49
cdentas far as benefit: not really sure, but we're kind of stuck with it because of some guarantees we've made about other code using the library14:49
cdentI was always very conflict about either of the ibraries14:50
*** openstackgerrit has quit IRC14:51
cdentefried: did you learn anything about request ids? I've realized I can't remember what handles the request id injection. i'm guessing the Context15:08
efriedcdent: I put those patches up and will get back to their results in a bit.15:08
efriedTheoretically:15:08
efried- The global request ID is stored in context.global_id on the nova side15:10
efried- We shove it into the request via a header X-Openstack-Request-Id15:10
efried- It's supposed to be included in the logs by any openstack service on the other end of that request, so you can trace a single "request" (like "create a VM") through all its machinations across various services, like by grepping a unified log file.15:10
* cdent nods15:13
cdentsupposed to be15:14
*** ttsiouts has quit IRC15:27
*** ttsiouts has joined #openstack-placement15:28
*** ttsiouts has quit IRC15:32
*** ttsiouts has joined #openstack-placement15:33
cdentlatest pupdate: https://anticdent.org/placement-update-19-29.html15:41
*** cdent has quit IRC16:01
*** cdent has joined #openstack-placement16:06
cdentI think I'm done. Any requests before I go?16:07
efried"The two main things on the Placement radar are implementing Consumer16:09
efriedTypes and cleanups, performance analysis, and documentation related16:09
efriedto nested resource providers."  <== reverse Rick Perry16:09
efriedHave a good evening.16:09
* cdent waves16:12
*** e0ne has quit IRC16:12
*** cdent has quit IRC16:12
*** ttsiouts has quit IRC16:17
*** ttsiouts has joined #openstack-placement16:17
*** ttsiouts has quit IRC16:22
*** tssurya has quit IRC16:23
*** mriedem is now known as mriedem_lunch16:35
*** mriedem_lunch is now known as mriedem17:50
*** openstackgerrit has joined #openstack-placement17:53
openstackgerritEric Fried proposed openstack/placement master: Do request_log middleware last  https://review.opendev.org/67302717:53
efriedcdent ^17:53
*** fungi has joined #openstack-placement19:05
*** artom has quit IRC21:06
*** jaypipes has quit IRC21:44
openstackgerritEric Fried proposed openstack/placement master: Extra gabbi tests for same_subtree  https://review.opendev.org/66993022:00
*** mriedem has quit IRC23:08

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