| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-26 | |||
| 16:04:41 | sean-k-mooney | leakypipes: numa and hugepages are unrelated to cpu affintiy execpt in nova... am it would help with testing with ovs-dpdk in the upstream ci in the future | |
| 16:04:43 | cfriesen | leakypipes: I don't really care about jumping through hoops to make TCG work better. | |
| 16:05:08 | cfriesen | leakypipes: sean-k-mooney: we use TCG for designer testing, but not for production | |
| 16:05:35 | sdague | cfriesen: well, a lot of those lame things were to make it a lot more clear when changing things where they ended up, and that no editor is going to help you edit yaml correctly nested inside an rst block :P | |
| 16:06:06 | sean-k-mooney | cfriesen: leakypipes basically the only thing that stops testing ovs-dpdk in the upstream ci is the fact that rackspcae uses zen so i cant rely on kvm being avaiable | |
| 16:06:55 | sean-k-mooney | cfriesen: leakypipes i have been trying to make it work with just qemu but sinc we generate cpu affinity info when we request numa/hugepages i cant use that either | |
| 16:07:47 | sean-k-mooney | cfriesen: leakypipes that said the TCG backend has a segfault bug in upstream qemu that they need to fix also so even then i would need that to be fixed to support my usecase | |
| 16:07:50 | cfriesen | sean-k-mooney: the newer qemu/libvirt must be more strict, under the same circumstances it works for us (but as I recall we're running somewhat older versions than you) | |
| 16:08:16 | sean-k-mooney | cfriesen: yes it only an issue with newer libvirt | |
| 16:08:28 | sean-k-mooney | i am using 3.3.0 and qemu 2.8 | |
| 16:09:52 | leakypipes | sean-k-mooney: well, I'll review the patch in a bit. not too thrilled obviously by it, but I'll review just because I like you. :) | |
| 16:09:54 | cfriesen | sean-k-mooney: honestly that seems like a libvirt bug, since it should still be able to affine the qemu process even if it can't affine the individual vCPU threads separately | |
| 16:10:43 | cfriesen | sean-k-mooney: it seems to me that libvirt should accept it as long as all vCPUs are affined the same | |
| 16:10:53 | sean-k-mooney | leakypipes: aw, offers of beer at next ptg hehe. | |
| 16:11:29 | sean-k-mooney | leakypipes: it not a high proity i just wanted to know if i should rebase and continue working on it or we dont care about the TCG backend | |
| 16:12:00 | sean-k-mooney | cfriesen: yes that was discused on libvirt mailing list tangentaly. | |
| 16:12:19 | sean-k-mooney | cfriesen: we are specificaly generating per core configurat which is invalad | |
| 16:12:35 | sean-k-mooney | cfriesen: affinties all the cores to the same set should work | |
| 16:12:35 | cfriesen | sean-k-mooney: I don't care about the backend except to the extent it enables ovs-dpdk in upstream CI. :) | |
| 16:12:50 | leakypipes | sean-k-mooney: I'm willing to review the patch if it's something you need to work on ovs-dpdk. | |
| 16:13:22 | sean-k-mooney | cfriesen: leakypipes ill ask infra if we can create a job that will only run on ci provides that use kvm | |
| 16:13:54 | sean-k-mooney | if they can provide that i dont need the change and i can test it upstream with a configuration that is closer to production | |
| 16:14:27 | sean-k-mooney | that is my preferend solution honestly but they were not to open to that the last time i asked | |
| 16:15:39 | sean-k-mooney | the whole motivation for this was i was asked to try and figure out how to also test ovs-dpdk upstream with odl and ovn but if i can do it with neutron i also blockes with an sdn controler | |
| 16:16:05 | leakypipes | k | |
| 16:38:43 | efried | sdague I pulled down your change and py27 passed all the way for me. | |
| 16:38:52 | efried | Did you maybe have an old venv? tox -r? | |
| 16:40:18 | sdague | efried: I did a -r | |
| 16:41:01 | efried | sdague hmph, can't explain it. | |
| 16:41:14 | sdague | yeh, neither can I, oh well | |
| 16:42:07 | efried | sdague Jenkins seems to agree with me, so yeah, oh well. | |
| 16:48:59 | sdague | efried: yeh, I'll completely blow away the directory at some point and reset | |
| 16:53:51 | sdague | ok, the oslo.middleware request_id change + mv 2.46 is green - https://review.openstack.org/#/c/467998 | |
| 17:25:08 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/468089 | |
| 17:29:02 | openstackgerrit | OpenStack Proposal Bot proposed openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/468494 | |
| 17:30:01 | openstackgerrit | Sean Dague proposed openstack/nova master: Updated from global requirements https://review.openstack.org/468089 | |
| 17:30:28 | sdague | melwitt: I'm sticking that behind the other one which is mv sensitive so that it doesn't cause a merge issue late | |
| 17:31:09 | sdague | melwitt: if you want to poke at https://review.openstack.org/#/c/467998 - it would be much appreciated | |
| 17:32:30 | melwitt | sdague: ack | |
| 17:35:58 | leakypipes | cdent: fabulous: "Your reward is a brief moment of respite from the despair of existence." | |
| 17:37:21 | cdent | leakypipes: you made it to the end! bask in this brief moment! | |
| 17:43:11 | leakypipes | cdent: :) | |
| 17:43:35 | cdent | too late, the moment is over | |
| 17:47:22 | mriedem | sdague: https://bugs.launchpad.net/nova/+bug/1693228 | |
| 17:47:22 | openstack | Launchpad bug 1693228 in OpenStack Compute (nova) "Nova quota show/set give errors in verify_project_id" [Undecided,New] | |
| 17:47:34 | mriedem | looks like some url munging problems http:// |
|
| 17:48:32 | melwitt | sdague, mriedem: do we need a reno on the mv 2.46 change? | |
| 17:48:40 | melwitt | for the new microversion | |
| 17:48:48 | mriedem | melwitt: umm, probably | |
| 17:49:02 | melwitt | other than that, it looks reasonable to me | |
| 17:49:06 | mriedem | sdague: does the global request id just get generated or does the user pass it in on the request? | |
| 17:49:28 | mriedem | either way, the point of the microversion is to signal to users that they can get that thing back from this cloud and use it to trace through other services | |
| 17:49:35 | mriedem | so it's probably good to call it out in release notes as a feature | |
| 17:49:42 | melwitt | yeah, was thinking the same | |
| 17:53:04 | sdague | mriedem: ok, so there are 2 things going on here, that are related, but slightly different | |
| 17:53:40 | sdague | global_request_id is an inbound value, with a request header of X-OpenStack-Request-ID | |
| 17:53:44 | sdague | you set that | |
| 17:53:52 | sdague | there is also an outbound response header | |
| 17:54:04 | sdague | X-OpenStack-Request-ID - which is locally generated | |
| 17:54:22 | sdague | that's been true for every service except Nova for years | |
| 17:54:35 | sdague | Nova was doing the same thing with X-Compute-Request-ID | |
| 17:55:19 | sdague | in order to get the inbound behavior without copy/paste we needed to adopt the oslo lib | |
| 17:55:25 | sdague | which meant getting the oslo behavior | |
| 17:55:45 | sdague | mriedem: I can add a reno | |
| 17:55:56 | mriedem | ok | |
| 17:56:09 | sdague | you want it in this patch, or a follow on? | |
| 17:56:13 | mriedem | same one | |
| 17:56:23 | sdague | ok, through the jenkins gauntlet again :) | |
| 17:59:57 | mriedem | lbragstad: jamielennox|away: can you take a look at this? https://bugs.launchpad.net/nova/+bug/1693228 | |
| 17:59:57 | openstack | Launchpad bug 1693228 in OpenStack Compute (nova) "Nova quota show/set give errors in verify_project_id" [Undecided,Triaged] | |
| 18:00:12 | lbragstad | mriedem: sure | |
| 18:00:19 | mriedem | since ocata nova tries to validate a project id in our quotas API by calling /v3/projects/{project_id} | |
| 18:00:37 | mriedem | this assumes you have keystone v3 since v2 has been deprecated since i think mitaka | |
| 18:00:51 | mriedem | the person in the bug report said that nova hard-coding /v3/ in the url prefix is wrong | |
| 18:00:52 | lbragstad | mriedem: i'm digging into some stable maintenance things for keystone at the moment, but i'll look into that next | |
| 18:00:53 | openstackgerrit | Sean Dague proposed openstack/nova master: Migrate to oslo request_id middleware - mv 2.46 https://review.openstack.org/467998 | |
| 18:01:12 | sdague | right, this is the versioned vs. unversioned keystone endpoint issue | |
| 18:01:22 | mriedem | ok - only thing that gives me pause is the v3 api-ref uses /v3/ too https://developer.openstack.org/api-ref/identity/v3/#show-project-details | |
| 18:01:31 | sdague | https://review.openstack.org/#/c/438049/ | |
| 18:01:58 | sdague | mriedem: so that's the result they will get if they made their identity url use the versioned one | |
| 18:02:21 | sdague | it's the same thing tripleo hit | |
| 18:03:18 | sdague | there is other keystoneauth magic we could lean on here | |
| 18:03:30 | sdague | the half baked patch I had died on the vine | |
| 18:04:38 | sdague | actually, I think https://review.openstack.org/#/c/438049/6/nova/api/openstack/identity.py might be the fix for them as well | |
| 18:04:54 | sdague | I didn't like it at the time because of how much magic hiding of issues it does | |
| 18:04:55 | mriedem | hit kolla too https://review.openstack.org/#/c/463500/ | |
| 18:06:28 | sdague | yeh. | |
| 18:06:33 | mriedem | so with that patch of yours, | |
| 18:06:49 | mriedem | they go from a 400 (because of endpoint not found) to a 404 (Because endpoint not found) | |
| 18:06:55 | mriedem | but with a helpful message | |
| 18:07:18 | sdague | actually, they wouldn't get a 404 | |
| 18:07:19 | mriedem | or does ksa actually do magic to find the right v3 endpoint? | |
| 18:07:25 | sdague | yep, it does | |
| 18:07:30 | mriedem | oh well that's neat | |
| 18:07:38 | sdague | that's the magic I wasn't all that comfortable with | |
| 18:07:43 | mriedem | oh | |
| 18:07:47 | mriedem | well | |
| 18:07:53 | sdague | but, honestly, it's probably the right UX for operators | |
| 18:07:59 | mriedem | yeah, plus upgrade impact isn't fun | |
| 18:08:03 | sdague | yep | |