Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-21
14:02:50 smcginnis No problem
14:10:55 mriedem SteelyDan: i'm confused by tssurya's change here https://review.openstack.org/#/c/567785/ which looks like it adds the new microversion handling, but the microversion isn't actually introduced in that change, it's spread throughout several other patches after that
14:11:22 mriedem is the idea that none of this works until the end of the series?
14:11:44 SteelyDan yeah, that's generally how we do this right?
14:12:38 mriedem well,
14:12:46 mriedem we generally plumb the lower layers with flags and such,
14:12:59 mriedem but that change is actually checking the version the user passed in is 2.66 and if so, does something
14:13:11 mriedem i just don't know if that would actually work yet until the MAX_VERSION is updated later
14:13:25 mriedem the risk is that 2.66 is already approved in another change
14:13:41 mriedem iow, normally the change that introduces the actual microversion is at the end
14:13:56 mriedem i think i'm going to procedurally -2 this until the rest of the series is +W
14:14:17 SteelyDan right, that's what I asked for earlier .. is that no tthis?
14:16:38 mriedem i left comments and a -2, can discuss with tssurya later
14:18:32 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Delete instance_id_mappings record in instance_destroy https://review.openstack.org/604373
14:20:55 mriedem jroll: we should probably make this VirtDriverNotReady thing for ironic a warning yeah? http://logs.openstack.org/27/602127/2/check/ironic-tempest-dsvm-ipa-wholedisk-bios-agent_ipmitool-tinyipa/4238d0f/controller/logs/screen-n-cpu.txt.gz?level=TRACE#_Sep_20_21_52_03_587436
14:20:56 mriedem or info?
14:21:04 mriedem it's just a case of n-cpu starting up before ironic api right?
14:21:11 mriedem and it's self-healing?
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

Earlier   Later