| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-31 | |||
| 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 | sdague | mriedem: where is that job definition | |
| 16:36:26 | mriedem | echo 'export LIVE_MIGRATION_AVAILABLE=True' | |
| 16:37:13 | mriedem | sdague: https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/devstack-gate.yaml#L1674 | |
| 16:37:13 | sdague | is that coming from project-config or d-g? | |
| 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 | 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: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 | mgould | any idea what I've done wrong? | |
| 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 | |
| 18:15:45 | sdague | right, that too | |
| 18:15:53 | dansmith | so, then, yeah, I need to run discover_hosts again after we've done the resource verify | |
| 18:17:04 | sdague | so, given the number of other things in flight, does this catch a failure that would have passed otherwise? Or is this just catching a failure earlier? | |
| 18:17:07 | dansmith | sdague: so, according to the plugin docs, I could run discover from resource verify post-upgrade I guess | |