Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-26
15:37:34 mriedem i'll change it and add comments
15:37:36 mriedem b/c otherwise it's confusing
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:///v3/v3/projects/
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

Earlier   Later