Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-05-26
15:28:00 mriedem i'll update tests in the meantime
15:29:00 superdan mriedem: do you understand why your test didn't catch this?
15:29:09 mriedem the functional one? no
15:29:19 mriedem i didn't dig into the fixture magic
15:29:20 superdan okay I'm still thinking on that
15:29:43 superdan in devstack land, cell0 is the default connection so it would make sense to have gotten a free pass because of that
15:30:10 superdan but with CellDatabases, it chooses cell1 to make the transition easier
15:30:34 melwitt I still don't get why the fix works. how does it make the instance findable via InstanceMapping?
15:31:11 superdan melwitt: it was failing to ever do the assignment because it failed the vm state update right?
15:31:32 superdan explote on L888 means it never ran L892?
15:31:35 superdan *explode
15:31:44 melwitt ohhh
15:32:13 melwitt right, thanks
15:32:55 melwitt so the tests are covering it because it's not only notifications, it's an instance.save() with the right context and verifying that
15:33:58 mriedem so i'm not changing anything right now then?
15:35:01 superdan I don't think we need to hold up on the context thing.. since it's very specifically not needed, I would probably have not used the targeted one, but not sure it's worth changing
15:35:17 superdan do you want to drill down on the functional test not catching it or no?
15:35:23 superdan if this is holding up people,
15:35:28 superdan an the trove test passes, I'd say we go
15:35:54 melwitt I'm cool with doing this now and looking into the functional test as a follow up
15:35:55 mriedem i changed the InstanceMapping.get_by_instance_uuid to use context instead of cctxt and no unit tests failed, so we're not asserting that
15:36:10 mriedem so i can change that back, or add an assertion, or do nothing in this change
15:36:23 mriedem it's an easy switch back to just using context for that call
15:36:27 superdan well, not validating it because it's not a big deal
15:36:37 superdan I'm cool with either, up to you
15:36:55 melwitt ditto
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 openstack Launchpad bug 1693829 in OpenStack Compute (nova) "name too long" [Undecided,New]
15:40:22 mriedem leakypipes: i added MOS to this https://bugs.launchpad.net/mos/+bug/1693829
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 openstack Launchpad bug 1693257 in OpenStack Compute (nova) "Policy doesn't allow os_compute_api:os-cloudpipe to be performed" [Undecided,New]
15:54:09 mriedem mtreinish: uh oh! https://bugs.launchpad.net/nova/+bug/1693257
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 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: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: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 mriedem untriaged bugs < 100 \o/
16:02:00 leakypipes sean-k-mooney: what precisely is the point of NUMA without CPU affinity?
16:02:04 mriedem time for lunch
16:02:04 sean-k-mooney mriedem: the if puts me over the 80 charter limit and pep8 complains
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 cfriesen sean-k-mooney: I don't care about the backend except to the extent it enables ovs-dpdk in upstream CI. :)
16:12:35 sean-k-mooney cfriesen: affinties all the cores to the same set should work
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

Earlier   Later