Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-21
14:23:20 mriedem gmann: i'm going to pull https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-stein out of the runway slot since there are no open changes
14:36:24 openstackgerrit Merged openstack/nova-specs master: Placement: any traits in allocation_candidate query https://review.openstack.org/565730
14:38:10 openstackgerrit Merged openstack/nova-specs master: Placement: support mixing required traits with any traits https://review.openstack.org/565741
14:39:59 openstackgerrit Rodolfo Alonso Hernandez proposed openstack/os-vif master: Add abstract OVSDB API https://review.openstack.org/476612
14:47:08 cdent How disabled is a compute node that's been administratively disabled (compute service disable...)? Can an admin stil force a migration there?
14:47:26 cdent SteelyDan, mriedem ^ ?
14:47:48 mriedem i think they can
14:47:54 mriedem b/c a force would bypass the ComputeFilter
14:49:18 openstackgerrit Matt Riedemann proposed openstack/nova master: Ignore VirtDriverNotReady in _sync_power_states periodic task https://review.openstack.org/604376
14:49:22 mriedem jroll: ^
14:49:42 cdent mriedem: is my understanding correct that there are two different kinds of force? one checks that the destination has the required resourcdes (and thus uses the sheduler/placement) and the other does not?
14:49:54 mriedem well,
14:50:00 mriedem there are a few ways to confuse 'force' here,
14:50:16 mriedem depends on the microversion used in the live migration api
14:50:28 mriedem https://developer.openstack.org/api-ref/compute/#live-migrate-server-os-migratelive-action
14:50:42 cdent anytime someone says "well" i want to run and hide
14:50:56 mriedem so before microversion 2.30, specifying the host bypasses the scheduler and forces it,
14:51:10 mriedem after microversion 2.30, if you specify a host but not force=true, the scheduler validates the host,
14:51:27 mriedem >=2.30 + host + force=true means bypass the scheduler
14:51:40 mriedem yes, it's terrible; mordred can attest when i explained this when he fixed it in the sdk
14:51:50 mriedem and it's also the reason i was -5 on adding force to cold migration
14:51:58 mriedem among other reasons
14:52:31 mriedem if it doesn't matter, always pass host=None
14:52:35 mriedem so the scheduler always picks
14:52:54 mriedem otheriwse use microversion >=2.30 so the scheduler validates the specified host
14:53:05 mordred yeah. I really didn't enjoy this one
14:53:06 cdent so: in >= 2.30 if i want to target a disabled compute node I can host + force = true and really truly force. That's the thing I'm after in this case.
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

Earlier   Later