Earlier  
Posted Nick Remark
#openstack-nova - 2018-09-21
16:22:09 mdbooth mriedem: How about testing NFS/LVM ;) https://bugs.launchpad.net/nova/+bug/1793159/comments/9
16:22:09 openstack Launchpad bug 1793159 in OpenStack Compute (nova) "no signature check for cached images" [Undecided,New]
16:22:40 mriedem lvm will be tested by the last change in that series now,
16:22:48 mriedem or do you mean lvm as the image backend, not volume-based?
16:23:01 mriedem we have an lvm job in the experimental queue i think but it's not multinode
16:23:06 mriedem same for nfs
16:23:09 mdbooth mriedem: I wasn't being serious, but I was suggesting instances on NFS and image backend=lvm
16:23:21 mriedem well, we could do those if we made the jobs multinode
16:23:22 mdbooth As that was the scenario described in that bug
16:24:24 mriedem i seem to remember having a todo to investigate integrating lvm into some other job of ours for additional coverage, related to something lyarwood was fixing awhile back
16:24:30 mriedem i'd have to dig that up
16:25:57 mdbooth mriedem: Incidentally, afaik there's absolutely no reason to ever use that configuration.
16:26:19 mriedem imagebackend=lvm?
16:26:28 mriedem windriver loved it until recently
16:26:33 mdbooth mriedem: Combined with instances on nfs
16:26:36 mriedem oh
16:26:51 mdbooth It seems like the worst of everything
16:28:39 mdbooth Yeah, lvm is a thing. I wonder what the performance advantage over raw files is, though. Bet it's minimal.
16:28:52 mriedem i guess i was thinking of this https://review.openstack.org/#/c/567860/ maybe
16:28:59 mriedem config drive with vfat
16:29:22 mriedem because of https://bugs.launchpad.net/nova/+bug/1771700
16:29:22 openstack Launchpad bug 1771700 in nova (Ubuntu Bionic) "nova-lvm tempest job failing with InvalidDiskInfo" [High,Fix committed]
16:30:11 mriedem http://paste.openstack.org/show/730550/
16:30:53 mriedem tl;dr: "so we could get images_type live migration coverage for qcow2, raw and rbd image types, with and without config drive, and with config drive vfat and iso9660."
16:31:41 mriedem right now our live migration jobs only test qcow2/rbd and without config drive ever
16:32:05 mdbooth It's quite a matrix :/
16:32:25 mdbooth mriedem: Add in with/without kernel/ramdisk
16:32:33 mriedem no one cares about those
16:32:50 mdbooth Hehe, they were a bug in my evacuate patch, though :)
16:34:05 mdbooth The fake imageservice was non-deterministically returning an image with kernel/ramdisk, which caused a failure in my functional test. The bug was real.
16:35:33 mdbooth mriedem: How much of test_evacuate.sh is boilerplate, btw?
16:35:43 mriedem as in virt agnostic?
16:35:58 mdbooth As in copied almost verbatim from another well-tested script
16:36:07 mriedem 0
16:36:10 mdbooth k
16:36:15 mriedem i wrote it while at the ptg last week
16:36:27 mriedem in between bouts of yelling "argh" at people
16:36:40 mriedem you were my muse you know
16:36:46 mdbooth You must have typed quickly in those gaps
16:36:50 mriedem heh
16:37:09 mriedem btw, assuming these evacuate test patches pass, we should run your fix on top of them,
16:37:16 mriedem could probably do that without rebasing
16:37:24 mriedem if you put a change on top of your fix that depends-on my stack
16:37:28 mdbooth mriedem: ack. I'll add a Depends-on to it now
16:37:37 mriedem don't put the depends-on your fix directly,
16:37:42 mriedem put it on a DNM patch on top of yours
16:37:50 mdbooth Oh, ok. Got it.
16:38:45 mdbooth I'll have to leave the detailed review for Monday now, though. I need to be somewhere in 50 minutes, and I need to both get home, eat, and travel there first.
16:38:53 mriedem yup, sure
16:38:54 mriedem ttyl
16:39:42 mriedem SteelyDan: stacking up a new devstack atm to test your placement db copy script thing, should hopefully be able to start writing grenade changes this afternoon
16:40:20 SteelyDan mriedem: ack.. did the projects thing for the grenade job get resolved?
16:40:25 SteelyDan I haven't really been paying attention
16:40:32 mriedem don't know
16:55:17 openstackgerrit Matthew Booth proposed openstack/nova master: Add regression test for bug 1550919 https://review.openstack.org/591733
16:55:17 openstack bug 1550919 in OpenStack Compute (nova) "[Libvirt]Evacuate fail may cause disk image be deleted" [Medium,In progress] https://launchpad.net/bugs/1550919 - Assigned to Matthew Booth (mbooth-9)
16:55:17 openstackgerrit Matthew Booth proposed openstack/nova master: Don't delete disks on shared storage during evacuate https://review.openstack.org/578846
16:55:51 openstackgerrit Matthew Booth proposed openstack/nova master: DNM: Test against mdbooth's evacuate patch https://review.openstack.org/604423
17:03:20 kashyap mriedem: Shall I bump the MIN_VERSION_* to the advertized NEXT_MIN_* here: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L230
17:03:35 kashyap (Will get to it on Monday; but just wanted to double-check here.)
17:06:17 openstackgerrit Merged openstack/nova stable/queens: Add tempest-slow job to run the tempest slow tests https://review.openstack.org/604134
17:17:10 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (7) https://review.openstack.org/571992
17:17:44 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (8) https://review.openstack.org/571993
17:21:46 openstackgerrit Merged openstack/nova stable/pike: Add tempest-slow job to run the tempest slow tests https://review.openstack.org/604138
17:21:53 openstackgerrit Merged openstack/nova master: Remove deprecated nova-consoleauth reference from doc https://review.openstack.org/604277
17:24:47 openstackgerrit Merged openstack/nova master: ironic: stop hammering ironic API in power sync loop https://review.openstack.org/602127
17:25:16 kashyap mriedem: When you're around, I should we should update it. Since we advertized them as the NEXT_MIN.
17:26:00 kashyap (That means, some more tedious, but necessary work, about selecting the NEXT_MIN_* for 'T' release.)
17:31:37 openstackgerrit sean mooney proposed openstack/nova master: libvirt: fix disk_bus handling for root disk https://review.openstack.org/584999
17:59:36 openstackgerrit Merged openstack/os-vif master: Fix upper-constraints link in tox file https://review.openstack.org/604158
18:47:10 openstackgerrit Mohammed Naser proposed openstack/nova stable/queens: Filter deleted computes from get_all_by_uuids() https://review.openstack.org/604448
18:48:02 openstackgerrit Mohammed Naser proposed openstack/nova stable/pike: Filter deleted computes from get_all_by_uuids() https://review.openstack.org/604449
18:52:30 openstackgerrit Mohammed Naser proposed openstack/nova stable/ocata: Filter deleted computes from get_all_by_uuids() https://review.openstack.org/604451
19:37:27 cfriesen is there an API equivalent to "nova-manage cell_v2 discover_hosts"?
19:38:52 mriedem cfriesen: no
19:39:03 mriedem there is a config option to run it periodically in the scheduler
20:00:11 openstackgerrit Matt Riedemann proposed openstack/nova master: Add volume-backed evacuate test https://review.openstack.org/604397
20:00:11 openstackgerrit Matt Riedemann proposed openstack/nova master: Run evacuate tests with local/lvm and shared/rbd storage https://review.openstack.org/604400
20:18:06 imacdonn mriedem: can I ask a "dumb" question or two about upgrade checks?
20:18:24 mriedem yes
20:19:11 imacdonn so ... my understanding of "nova-status upgrade check" is that it's something that would be run *after* upgrading (db sync, etc), to check that everything is OK to proceed
20:19:25 imacdonn now it sounds like you want to do checks for things that should be done BEFORE the upgrade in there
20:19:43 imacdonn which is it?
20:22:10 mriedem it's meant to be run before starting new code
20:22:24 mriedem but that's not really a hard and fast rule
20:22:36 imacdonn but ... before or after upgrading the database ?
20:22:37 mriedem i.e. you can also run the nova-status upgrade check as a post-install step for a fresh install
20:22:44 imacdonn (databases)
20:22:49 mriedem after
20:23:09 imacdonn OK, so then ... it seems like it's not the right place for pre-upgrade checks
20:23:27 imacdonn there could be things you'd want to check before you try to upgrade the databases
20:23:48 mriedem well, depends on what your db upgrades are doing
20:23:58 mriedem are they doing data migrations during db sync?
20:24:01 mriedem b/c they really shouldn't
20:24:53 imacdonn hmm, I guess I don't know enough about the db internals ... I kinda thought that that's what db sync does
20:25:27 imacdonn if not where, where should the migrations happen? on first startup after upgrade ?
20:25:28 mriedem nova's db sync routines which lay down schema are primarily only for additive schema changes, like adding tables, columns and indexes/constraints
20:25:39 mriedem not for things that involve data migrations
20:25:49 mriedem during runtime
20:26:08 mriedem e.g. if you need to change the format for some value stored in the db, check on read and update on write

Earlier   Later