Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-31
16:17:47 mdbooth dansmith: Sorry, was internally also trying to justify being against https://review.openstack.org/#/c/402318/
16:19:48 lyarwood dansmith: yeah AFAICT we just didn't make it to cleanup before your patch
16:20:20 dansmith so, to restate, I think we should merge lyarwood's patch
16:20:50 lyarwood cool thanks
16:20:51 mdbooth dansmith: Yeah. Reviewing now.
16:34:53 mriedem sdague: did you see this? http://lists.openstack.org/pipermail/openstack-dev/2017-January/111137.html
16:35:07 mriedem sdague: i was wondering if the new devstack-tools stuff somehow screwed up local.conf for multinode grenade?
16:35:43 sdague mriedem: it's possible, though I thought I had that covered
16:36:22 mriedem we know d-g is setting it http://logs.openstack.org/61/417961/40/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/8c363cd/console.html.gz#_2017-01-27_23_16_09_271784
16:36:26 mriedem echo 'export LIVE_MIGRATION_AVAILABLE=True'
16:36:26 sdague mriedem: where is that job definition
16:37:13 sdague is that coming from project-config or d-g?
16:37:13 mriedem sdague: https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/devstack-gate.yaml#L1674
16:37:22 mriedem echo 'export LIVE_MIGRATION_AVAILABLE=True' is from d-
16:37:24 mriedem *d-g
16:37:40 mriedem sdague: https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh#L542
16:38:09 mriedem sdague: the weird thing i noticed was,
16:38:12 mriedem looking at the local.conf http://logs.openstack.org/61/417961/40/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/8c363cd/logs/new/local.conf.txt.gz
16:38:20 mriedem NOVA_ALLOW_MOVE_TO_SAME_HOST=False is in there
16:38:25 mriedem from https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh#L541
16:38:34 mriedem but export LIVE_MIGRATION_AVAILABLE=True isn't
16:38:40 mriedem so i'm wondering if the export is screwing it up
16:40:46 sdague yeh, it's litterally using the export bit
16:41:25 sdague mriedem: you want to do a depends on https://review.openstack.org/427282 and see if that addresses things?
16:42:04 mriedem sure
16:42:06 sdague I took a strategy of doing a merge for valid looking lines, so you don't just have clobber clobber clobber going on, but that means understanding the kind of lines that can be brought over
16:43:09 mdbooth lyarwood: Done.
16:44:34 sdague mriedem: yeh - http://logs.openstack.org/61/417961/40/check/gate-grenade-dsvm-neutron-multinode-live-migration-nv/8c363cd/logs/grenade.sh.txt.gz#_2017-01-27_23_16_19_637
16:45:07 openstackgerrit Matt Riedemann proposed openstack/nova: DNM: testing grenade multinode + live migration fix https://review.openstack.org/427285
16:45:41 mriedem skipped LIBS_FROM_GIT since there was no valid right?
16:45:43 lyarwood mdbooth: thanks, I'll sort that out now
16:48:30 sdague mriedem: yeh
16:48:35 sdague because there was no value
16:48:49 mriedem sdague: ok. pointed out OS_NO_CACHE in the review too
16:48:55 mriedem otherwise lgtm
16:49:00 mriedem got the nova change up to test it
16:51:02 sdague mriedem: honestly, I'd leave the OS_NO_CACHE bit for now. I get it's probably also wrong, but it's not impacting anything right now.
16:51:13 sdague and, I'm not convinced it does anything useful anymore anyway
16:52:25 mriedem yeah hmm, looks like that's all dead code http://git.openstack.org/cgit/openstack-dev/devstack/tree/openrc#n56
16:53:27 mriedem lots of stuff setting it, but nothing using it http://codesearch.openstack.org/?q=OS_NO_CACHE&i=nope&files=&repos=
16:59:44 sdague mriedem: yeh
17:00:04 sdague there were definitely a few things I noticed in d-g that were completely dead config settings
17:12:36 openstackgerrit Lee Yarwood proposed openstack/nova: libvirt: Limit destroying disks during cleanup to spawn https://review.openstack.org/427267
17:14:07 openstackgerrit Chris Dent proposed openstack/nova: WIP: Explore functional test for the resource tracker https://review.openstack.org/427309
17:15:04 mgould hi everyone
17:15:06 mgould I'm getting "Host is not mapped to any cell" errors in nova boot on a clean devstack on a freshly-installed baremetal machine
17:15:28 mgould I've previously used the same local.conf on a VM without issues
17:15:34 mgould any idea what I've done wrong?
17:15:34 openstack bug 1646896 in OpenStack Compute (nova) "System hangs when using NFS storage backend with loopback mounts" [Low,Confirmed] https://launchpad.net/bugs/1646896
17:15:34 openstackgerrit Mihail proposed openstack/nova: proposed fix for bug 1646896 - System hangs when using NFS storage backend with loopback mounts, Closes-Bug: #1646896 https://review.openstack.org/422041
17:16:07 cdent jaypipes, edleafe, johnthetubaguy, mriedem : that review ^ about functional test for resource provider is trying to the basis for one that tests ironic. at the moment is just does non ironic
17:16:14 cdent I needed to start there to get any traction
17:17:00 jaypipes cdent: hmm, I was right in the middle of adding a functional test to the Ironic resource classes patch.
17:17:18 cdent ah, good, now we'll have more
17:17:21 cdent ;)
17:17:42 cdent that one is very bland
17:18:56 cdent jaypipes: perhaps we can compare and contrast later. I'm going to fix a couple bugs I found while making that.
17:22:24 jaypipes cdent: k
17:22:50 cdent if my version is for naught, was an excellent learning exercise
17:27:26 openstackgerrit Diana Clarke proposed openstack/nova: Fix map_cell_and_hosts help https://review.openstack.org/422171
17:28:00 openstackgerrit Chris Dent proposed openstack/nova: Fresh resource provider in RT must have generation 0 https://review.openstack.org/427319
17:40:38 openstackgerrit Chris Dent proposed openstack/nova: [placement] Use modern attributes of oslo_context https://review.openstack.org/427330
17:41:36 cdent mriedem: both of those ^ might be rc oriented
17:41:57 mriedem i +2ed the first one
17:42:18 mriedem https://review.openstack.org/#/c/427319/ isn't a regression in ocata though right? it was just always that way
17:47:48 cdent mriedem: not a regression, no, but sending out something with noise on it seems untidy
17:50:09 mriedem sure, but we're also 2 days from rc1
17:50:17 mriedem so i can live with untidy
17:50:21 mriedem since we can backport fixes
17:50:32 mriedem anyway, i'm +2 on it since it's a simple fix
17:50:54 cdent mriedem: that's cool. All this release schedule stuff is voodoo to me. I just smile and nod.
17:50:57 dansmith jroll: sdague: so, we really need to be running discover_hosts after compute nodes are in the database, which for ironic happens pretty late compared to other virt drivers
17:51:17 dansmith jroll: sdague: should I try to wedge in a discover_hosts call into the late stages of ironic devstack stuff?
17:52:28 dansmith jroll: sdague: or maybe it's futile if people don't provide ironic nodes at the time of a devstack run? I'm not actually sure how that works
17:55:52 mriedem cdent: it's pretty simple, just don't risk putting anything in right before rc1 unless it's super low risk, or super critical to get in
17:56:07 mriedem since you don't want to release a major version with some kind of major bug which prevents upgrades or something
17:56:09 mriedem ha
17:56:30 cdent I understand the mechanics.
17:56:36 mriedem having said all that, i'd bet most deployments wait much longer to pick up anything,
17:56:42 cdent that
17:56:44 mriedem so when they upgrade, they're going to pick up like the 3rd stable branch release anyway
18:01:11 mriedem cdent: before you dine,
18:01:18 cdent mriedem: yessir?
18:01:28 mriedem did either you or bauzas put anything up for the placement upgrade stuff in the devref? if not, i can start that
18:01:31 mriedem it will be pretty simple
18:01:34 mriedem just upgrade from newton notes
18:01:40 cdent I did not
18:01:43 mriedem bauzas: ?
18:01:58 mriedem ok i'll get started on that one
18:02:04 cdent thanks
18:10:19 dansmith sdague: question for you here: https://review.openstack.org/#/c/426310
18:12:07 sdague dansmith: ok, question away
18:12:17 dansmith sdague: it's in the review
18:12:26 dansmith about verify_noapi
18:14:26 sdague how can this run when the api is down?
18:14:35 dansmith sdague: there are other ways to solve this, including some sort of post phase for the plugin, where we've already run the verify, if you'd prefer
18:14:38 dansmith sdague: it's nova-manage
18:14:40 sdague it all depends on 'nova service-list'
18:14:59 dansmith oh, did I do it with service-list? I did..
18:15:33 dansmith I don't actually care that the api is down, of course, although I guess that means we won't have the primary node compute up either

Earlier   Later