| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-26 | |||
| 15:38:27 | mriedem | i'll recheck the trove change on this one too | |
| 15:38:35 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use targeted context when burying instances in cell0 https://review.openstack.org/468401 | |
| 15:39:11 | efried | sdague py27 finished with one failure for me: http://paste.openstack.org/show/610750/ | |
| 15:40:22 | mriedem | leakypipes: i added MOS to this https://bugs.launchpad.net/mos/+bug/1693829 | |
| 15:40:22 | openstack | Launchpad bug 1693829 in OpenStack Compute (nova) "name too long" [Undecided,New] | |
| 15:40:27 | mriedem | in case you guys have triage people | |
| 15:40:48 | leakypipes | k | |
| 15:42:28 | viks | Hi seeking attention on https://review.openstack.org/#/c/468089/ . Need one more verification :) | |
| 15:44:05 | viks | thanks mriedem | |
| 15:51:47 | openstackgerrit | Claudiu Belu proposed openstack/nova master: POC: tests: autospecs all the mock.patch usages https://review.openstack.org/447505 | |
| 15:54:09 | mriedem | mtreinish: uh oh! https://bugs.launchpad.net/nova/+bug/1693257 | |
| 15:54:09 | openstack | Launchpad bug 1693257 in OpenStack Compute (nova) "Policy doesn't allow os_compute_api:os-cloudpipe to be performed" [Undecided,New] | |
| 15:54:16 | mriedem | there might have been 1 cloudpipe user in the wild | |
| 15:55:15 | mtreinish | mriedem: haha, well they're in for a surprise in pike | |
| 15:56:52 | sean-k-mooney | hi o/ | |
| 15:58:24 | sean-k-mooney | mriedem: leakypipes sfinucan can i ye take a look at https://bugs.launchpad.net/nova/+bug/1691178 and https://review.openstack.org/#/c/465160/ | |
| 15:58:24 | openstack | Launchpad bug 1691178 in OpenStack Compute (nova) "virt_type=qemu does not support cpu affinity." [Undecided,New] - Assigned to sean mooney (sean-k-mooney) | |
| 15:58:55 | mriedem | mtreinish: i don't think they understand policy anyway, | |
| 15:59:01 | mriedem | it's admin-only by default and they are probably using non-admin | |
| 15:59:29 | mriedem | sean-k-mooney: you realize that's going to require tests | |
| 15:59:35 | sean-k-mooney | mriedem: leakypipes superdan just wondering if this is a bug you want to fix/ should i also adress this when selecting the host? | |
| 15:59:38 | sean-k-mooney | mriedem: yes | |
| 15:59:47 | mriedem | i don't know anything about this code | |
| 16:00:08 | sean-k-mooney | mriedem: qemu without kvm/zen does not support cpu affinity | |
| 16:00:41 | sean-k-mooney | we generate vcpu-pin ellement anyway and the vm fails to boot with a livbirt error | |
| 16:00:50 | cfriesen | sdague: does the api-ref changes in https://review.openstack.org/#/c/434514 match what you were looking for? (incidentally, it's lame that the min/max version is in parameters.yaml instead of the *.inc files, it leads to duplicated entries differing only in min/max version) | |
| 16:00:53 | leakypipes | sean-k-mooney: on the bug report, you put expected result that the VM starts with a virt topology. however, TCG doesn't support NUMA so how is that right? | |
| 16:01:04 | mriedem | sean-k-mooney: do you need to have that refactor in there? | |
| 16:01:41 | sean-k-mooney | leakypipes: numa is supprot cpu affinity is not | |
| 16:02:00 | leakypipes | sean-k-mooney: what precisely is the point of NUMA without CPU affinity? | |
| 16:02:00 | mriedem | untriaged bugs < 100 \o/ | |
| 16:02:04 | sean-k-mooney | mriedem: the if puts me over the 80 charter limit and pep8 complains | |
| 16:02:04 | mriedem | time for lunch | |
| 16:02:09 | cfriesen | leakypipes: TCG still lets you call the "virsh vcpupin" APIs, it just doesn't always give the expected results when you have multiple vCPUs. | |
| 16:02:16 | mriedem | sean-k-mooney: refactor in a separate change | |
| 16:02:38 | cfriesen | leakypipes: TCG still supports hugepages | |
| 16:02:52 | sean-k-mooney | mriedem_bbq: cool no problem ill do that and ill also add tests | |
| 16:03:12 | leakypipes | cfriesen: guh. | |
| 16:03:28 | sean-k-mooney | mriedem_bbq: just wanted to know if people were ok with me "fixing" the bug or if i should spend time on something else | |
| 16:03:40 | leakypipes | cfriesen, sean-k-mooney: honestly, why are we going out of our way to support this kind of thing for an emulator nobody will use in production? | |
| 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 | |