Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-20
14:44:53 sdague bauzas: well, a long working patch is better than a non working one
14:45:45 bauzas sdague: leakypipes: bingo https://github.com/openstack/nova/blob/master/nova/tests/functional/api/openstack/placement/gabbits/aggregate.yaml#L7
14:45:54 leakypipes sdague, bauzas: guys...
14:46:19 leakypipes sdague, bauzas: what is it you are trying to do?
14:46:20 bauzas leakypipes: because of that, we could be missing the placement upcall from the scheduler for Ocata...
14:46:42 bauzas just because we wanted to have a very separate WSGI app than the existing one
14:46:49 bauzas and using gabbi too
14:46:53 leakypipes bauzas: I'm not following you. How does a functional test fixture that disables Keystone auth impact the "scheduler upcall"?
14:46:57 sdague leakypipes: there is a need to get placement running inside the functional tests that aren't gabbi so you can have the whole working service collection
14:47:10 bauzas leakypipes: see my scheduler change and the functional tests job
14:47:33 bauzas we're getting NoValidHosts because the placement service isn't running
14:47:44 bauzas so I'm working since this morning on adding a fixture
14:47:46 leakypipes bauzas: and how is that related to gabbi?
14:48:03 bauzas leakypipes: because we have an existing fixture that is only gabbi'd
14:48:20 leakypipes bauzas: I have no idea what that means.
14:48:20 mriedem so let's ignore gabbi :)
14:48:24 mriedem the point is,
14:48:30 bauzas and when we added the placement service in Newton, we haven't verified that we could be adding a fixture for the existing tests
14:48:38 bauzas anyway
14:48:40 mriedem we need to run the placement service with a fixture, like we do for other services
14:48:48 mriedem like n-cond, n-sch, n-cpu, etc in the functional tets
14:48:49 mriedem *tests
14:48:50 bauzas I don't want to diverge too moch
14:48:51 sdague leakypipes: there exists no infrastructure in nova functional tests to start a running placement service outside of gabbi tests
14:48:53 mriedem those rely on a noauth fixture
14:48:55 mriedem since we don't have keystone
14:48:59 bauzas given the very short deadline
14:49:09 bauzas so folks, I'll be providing a WIP by the next 10 mins
14:49:37 mriedem we have an api client fixture for n-api for the functional tests, seems we'd want something similar for placement,
14:49:56 mriedem or simply have a PlacementFixture which isn't a real service
14:49:57 sdague mriedem: it's a little different than that because of the way things glue together
14:50:06 sdague but, yeh, bauzas is working through it
14:50:08 mriedem because when placement is split out, we'll need to just stub it anyway
14:50:11 mriedem like neutron
14:50:16 bauzas sdague: mriedem: lemme upload it
14:51:20 leakypipes bauzas: you're saying you need one of these for the placement API service, yes? https://github.com/openstack/nova/blob/master/nova/tests/fixtures.py#L638
14:51:37 bauzas leakypipes: I'm just adding it now since this morning
14:51:46 bauzas leakypipes: lemme upload it in the next 10 mins
14:52:20 leakypipes bauzas: ok. I just get annoyed with the kvetching about gabbi and "a separate WSGI service" when really this isn't that hard of a problem to solve.
14:52:51 bauzas leakypipes: it took me 1 hour for finding a solution because the WSGI placement service is not an oslo.service
14:52:55 leakypipes bauzas: gabbi tests a REST API interface. it doesn't test integration between two services.
14:53:04 bauzas fortunately, sdague gave me a good solution
14:54:24 sdague leakypipes: which we all understand, it's that we also test more than just that, and it wasn't anticipated. And because this was plumbed differently it takes more effort to plumb something in.
14:58:48 sdague oh, man, so happy to have gotten the anchor issue fixed in os-api-ref
14:58:59 sdague links should be a ton more useful in sharing now
14:59:39 sdague http://developer.openstack.org/api-ref/compute/?expanded=pause-server-pause-action-detail#pause-server-pause-action - for instance
14:59:41 melwitt johnthetubaguy: that's an excellent question. I should have asked you to review earlier :) what mriedem said is right, it was separated based on resource type (fixed_ips, networks, floating_ips in Quotas, everything else in ProjectUserQuota). I'll take a closer look and think about it
15:01:01 johnthetubaguy melwitt: oh, I thought everything could be in both, depending on the resource type, its not as bad if we just get to kill a table later
15:01:45 johnthetubaguy melwitt: but reading more, I am leaning towards the direct swap being simpler
15:01:57 melwitt johnthetubaguy: I think you're probably right. just not totally sure off the top of my head. and yes, also true that at worst (if we don't change it now) that it would be a table kill later
15:03:05 mriedem sdague: heh, for cyborgs such as yourself that actualy read the anchor :)
15:03:51 sdague mriedem: well, the point is that when you click the link button on the side, it updates the address bar correctly now
15:04:11 sdague so when people copy and paste links around, you can actually go to the right place in the page
15:04:12 johnthetubaguy sdague: thats quite lovely
15:04:25 sdague instead of having to search to find it
15:06:51 mriedem i just got used to right-clicking to copy the link
15:07:03 mriedem these are all creature comforts
15:07:28 sdague mriedem: well, now it just works like it should :)
15:10:42 openstackgerrit Wang Qing wu proposed openstack/nova: WIP(5): Introduce base PowerVM driver (ovs vif) https://review.openstack.org/422512
15:12:56 melwitt johnthetubaguy: what did you mean by "direct swap?" changing it now or later? one thing I just thought of is, after we remove nova-network, we'll also need to remove the quota limits for networks, fixed_ips, and floating_ips and maybe that would be simpler if they're all in the same table
15:14:46 johnthetubaguy melwitt: direct swap: I meant the DB methods matching so closely, is really handy
15:15:00 melwitt oh, I see
15:15:00 johnthetubaguy melwitt: yeah, if they are isolated in that way, its worth keeping
15:15:27 johnthetubaguy I totaly garbled that previous message, my bad
15:15:55 johnthetubaguy melwitt: still reading through the series for proper context, it feels close on those bottom patches
15:17:51 mriedem melwitt: we're not dropping nova-network in ocata, so anything hinging on that should be deferred
15:21:04 melwitt johnthetubaguy: cool. on the online migration patch I realized I should add a catch of DBDuplicateEntry for the limit create in case of someone interrupting it after limits migrated to api db but before limits deleted from main db
15:21:39 johnthetubaguy melwitt: ah, cools, not really got through that one yet
15:22:06 claudiub|2 mriedem: hi. any chance for the hyper-v pci stuff? i've posted a comment with a sample instance + pci spawn and proof that it worked (+ logs, flavors, .conf files): https://review.openstack.org/#/c/420614/
15:22:14 melwitt limits are migrated in one transaction but the delete is a separate one, separate db. there's no dupe detection possible for the quota classes. I should probably do something like that manually maybe
15:22:39 mriedem claudiub|2: would be good to get moshele, lbeliveau and sfinucan to take a look at that
15:27:45 openstackgerrit Sergey Nikitin proposed openstack/nova: Change parent of diagnostics objects to NovaObject class https://review.openstack.org/394480
15:27:45 openstackgerrit Sergey Nikitin proposed openstack/nova: Standardization of VM diagnostics info API. https://review.openstack.org/355540
15:27:46 openstackgerrit Sergey Nikitin proposed openstack/nova: Completed implementation of instance diagnostics for Xen https://review.openstack.org/399613
15:34:37 openstackgerrit Ritesh proposed openstack/nova: CPU pinning to consider single set of vcpus https://review.openstack.org/423334
15:42:31 mdbooth johnthetubaguy: We discussed this at the last summit: https://review.openstack.org/#/c/383859/ . It passes all the CI we've got, and I've been hammering on a version of it wrt a customer bug. Seems robust. Any chance you could take a look?
15:45:04 openstack Launchpad bug 1421550 in OpenStack Compute (nova) "Creating VM image fails under the race condition with detaching volume" [Medium,In progress] - Assigned to Matthew Booth (mbooth-9)
15:45:04 mdbooth It's a fix for this bug, btw: https://bugs.launchpad.net/nova/+bug/1421550
15:45:22 openstackgerrit Ritesh proposed openstack/nova: CPU pinning to consider single set of vcpus https://review.openstack.org/423334
15:46:13 melwitt mriedem: I dunno if you saw I made a couple of tweaks to the instance creation patch and it passed tests. so I was hoping you could take a look and point out any issues with the current state of it, before you go on vacation
15:46:27 johnthetubaguy mdbooth: its on my queue, but if I am honest, best to ping me just after feature freeze
15:46:43 mdbooth johnthetubaguy: Bug fixes are good after FF?
15:47:30 johnthetubaguy mdbooth: yes, assuming they are not features, and not going to risk hitting RC
15:47:32 melwitt mriedem: I saw that you've rechecked it as you've updated the d-g change
15:48:43 mriedem melwitt: yeah i saw it was passing except for the multinode job
15:48:51 mriedem which i'm hoping my d-g change to run discover_hosts will fix
15:49:12 melwitt okay, cool. I'm keeping an eye on the test run
15:56:38 openstackgerrit Feodor Tersin proposed openstack/nova-specs: Add ScaleIO ephemeral storage backend https://review.openstack.org/304715
16:00:31 mriedem melwitt: hmm for some reason in this run it didn't run discover_hosts.sh http://logs.openstack.org/05/423005/3/check/gate-neutron-dsvm-functional-ubuntu-xenial-nv/df5f610/logs/
16:00:39 mriedem my bash test for the existence of the file might be busted
16:01:09 melwitt mriedem: I saw this on one of the grenade runs http://logs.openstack.org/79/319379/64/check/gate-grenade-dsvm-neutron-ubuntu-xenial/49c8367/console.html#_2017-01-20_15_53_00_248820
16:01:24 mriedem yeah that's old
16:01:29 mriedem i fixed the permissions on the script
16:01:29 melwitt oh
16:01:41 melwitt hm, well it just did it just now
16:02:38 mriedem http://logs.openstack.org/05/423005/3/check/gate-grenade-dsvm-neutron-ubuntu-xenial/e2dfc17/console.html#_2017-01-20_15_54_01_719388
16:03:54 mriedem hrm
16:03:55 mriedem do i need to run the test as the stack user?
16:03:55 mriedem where the discover_hosts.sh file doesn't exist
16:03:55 mriedem something is busted because it's also trying to run it on mitaka http://logs.openstack.org/05/423005/3/check/gate-tempest-dsvm-full-ubuntu-trusty-mitaka-nv/27e2070/logs/devstack-gate-discover-hosts.txt.gz

Earlier   Later