Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-21
14:53:16 mriedem yes i think so
14:53:34 mriedem there are big red warnings in the api ref about it too
14:54:05 cdent cool, thank you very much. I think I've just learned a lot in a very short space of time, which is pleasing.
14:54:11 mordred cdent: http://git.openstack.org/cgit/openstack/openstacksdk/tree/openstack/compute/v2/server.py#n366 if you want to see it all in python
14:55:39 mriedem ghostbusters?
14:55:56 mriedem i guess that would actually be bad for their business
14:57:33 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Optimize AZ lookup during schedule_and_build_instances https://review.openstack.org/604378
14:58:46 mriedem SteelyDan: lyarwood: when you get a chance, could use reviews on these simple backports to run tempest-slow in queens and pike https://review.openstack.org/#/q/topic:nova-slow+(status:open+OR+status:merged)
14:59:06 mriedem b/c we merged a change in tempest to move several tests from tempest-full to tempest-slow so we should make sure we still have the test coverage on stable
15:04:05 lyarwood mriedem: ack looking now
15:07:38 mriedem alex_xu: have you talked with the cyborg devs at all about your nvdimm stuff to see if that could work with cyborg as a generic way to model those devices and integrate with nova for the plug/unplug that's needed via the os-acc library?
15:08:20 mriedem alex_xu: in general, i think we could really use someone that knows how nova works helping the cyborg team directly; fried_rice has been doing that but is also really busy with other stuff too.
15:09:03 lyarwood mriedem: remind me, nova-next is the cellsv2 job right?
15:09:22 mriedem lyarwood: in the olden times nova-next was cells v2 and placement while those were optional (in newton yeah)
15:09:43 SteelyDan all jobs should be cellsv2 with superconductor these days no?
15:09:46 mriedem yes
15:09:55 mriedem that's why we don't run nova-next on ocata/pike
15:09:55 lyarwood yeah I just couldn't recall what we used it for now
15:10:12 mriedem it's also the only job that runs our post-test scripts
15:10:43 mriedem the job description in .zuul.yaml explains what it runs
15:10:54 mriedem it runs the tls console proxy code since queens
15:10:59 mriedem and the service user token stuff since pike
15:11:10 mriedem so it's a smorgasbord of optional nova things not tested elsewhere
15:11:19 lyarwood cool, thanks
15:20:40 openstackgerrit Michal Arbet proposed openstack/nova master: Add check if api_database.connection is set. https://review.openstack.org/604388
15:25:31 openstackgerrit Michal Arbet proposed openstack/nova master: Add check if api_database.connection is set. https://review.openstack.org/604388
15:27:52 mriedem giblet: i have a few questions in https://review.openstack.org/#/c/591597/
15:28:07 mriedem i think it's OK for the most part, except we could be leaking a 500 response in the DELETE /servers/{server_id} API
15:29:51 cdent fried_rice, giblet : besides this topic https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/use-nested-allocation-candidates is there other "make nested work" stuff in progress?
15:30:26 fried_rice heh, probably.
15:30:58 fried_rice I assume you mean besides the stuff that consumes it (e.g. vgpu)
15:31:17 cdent (yes to second question) I figured, and I'll endeavor to find it, but thought I'd check for a quickref first
15:31:34 alex_xu mriedem: I'm thinking nova first since I think it is memory device. but actually, I never thing about how to integrate with cyborg
15:32:56 alex_xu mriedem: I didn't contribute too much for cyborg spec, but Sundar used to catch me discuss something
15:35:20 mriedem if it could work with cyborg, then it would be a win-win if you worked on it that way since they need someone that understands nova to help them integrate i think
15:35:51 mriedem obviously not on your friday night
15:37:22 alex_xu mriedem: got it, i will take a look at that
15:46:16 openstackgerrit Matt Riedemann proposed openstack/nova master: Add volume-backed evacuate test https://review.openstack.org/604397
15:47:15 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add native implementation OVSDB API https://review.openstack.org/482226
15:50:35 openstackgerrit Matt Riedemann proposed openstack/nova master: Run evacuate tests with local/lvm and shared/rbd storage https://review.openstack.org/604400
15:50:47 mriedem mdbooth: ^ those two additional changes should give a pretty healthy evacuate integration test coverage
15:50:57 mriedem local/lvm and shared/rbd
15:51:02 mriedem image-backed and volume-backed
15:54:50 openstackgerrit Matt Riedemann proposed openstack/nova master: Run evacuate tests with local/lvm and shared/rbd storage https://review.openstack.org/604400
15:54:50 openstackgerrit Matt Riedemann proposed openstack/nova master: Add volume-backed evacuate test https://review.openstack.org/604397
16:02:14 mdbooth mriedem: Looking now, thanks
16:02:41 openstackgerrit Michal Arbet proposed openstack/nova master: Add check if api_database.connection is set. https://review.openstack.org/604388
16:02:44 sean-k-mooney mriedem: hi i meant to ask you at the ptg but can you take a look at https://review.openstack.org/#/c/587615/ and comment if you want us to squash this and the next change into one or if this is ok. melwitt and finucannot wanted your input before merging for backport reasons
16:05:19 mriedem sean-k-mooney: without looking at details i'd squash them,
16:05:41 mriedem we normally only do the 2-change dance for a regression test when it's a much larger functional regression test that is actually hitting the api and such and shows a regression
16:05:56 mriedem otherwise if it's just unit tests, removing the code fix should show the test fails
16:19:08 sean-k-mooney mriedem: ya that was thw main question. i know the two step thing is normally only dont for functional test. ill squash them
16:19:20 sean-k-mooney mriedem: it will make finucannot happy anyway
16:22:09 openstack Launchpad bug 1793159 in OpenStack Compute (nova) "no signature check for cached images" [Undecided,New]
16:22:09 mdbooth mriedem: How about testing NFS/LVM ;) https://bugs.launchpad.net/nova/+bug/1793159/comments/9
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 openstack Launchpad bug 1771700 in nova (Ubuntu Bionic) "nova-lvm tempest job failing with InvalidDiskInfo" [High,Fix committed]
16:29:22 mriedem because of https://bugs.launchpad.net/nova/+bug/1771700
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.

Earlier   Later