Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-04
17:35:14 mriedem why is conductor failing on the reschedule
17:35:15 mriedem ?
17:35:34 edleafe Because it is confirming that the instance has allocations on the source
17:35:55 edleafe But at that point on a retry, it's the migration that has allocations on the source
17:35:55 mriedem yeah, which should be the case if we got here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4000
17:36:00 mriedem not if we did ^
17:36:38 mriedem is that failing?
17:37:37 edleafe dunno - all I know is that the instance didn't have allocations on the source. Let me check that out.
17:43:58 mriedem i've created https://bugs.launchpad.net/nova/+bug/1741307 to deal with the caching scheduler + resize stuff
17:43:59 openstack Launchpad bug 1741307 in OpenStack Compute (nova) "Resize always fails when using the CachingScheduler" [High,Triaged] - Assigned to Matt Riedemann (mriedem)
17:45:12 mriedem kashyap: fyi that i updated the devstack patch to test multiattach to set CONF.libvirt.images_type=raw and CONF.use_cow_images=False to see if that makes a difference
17:48:57 openstackgerrit Merged openstack/nova master: Revert "Modify _poll_shelved_instances periodic task call _shelve_offload_instance()" https://review.openstack.org/530284
18:19:19 mriedem wow, if i'm reading his results correctly, Kevin_Zheng got a 90% improvement in listing instances with details using an ip filter after we proxy to neutron first
18:19:25 mriedem sdague: ^
18:19:40 mriedem 2000 instances in nova and 2K ports in neutron
18:21:04 mriedem told him to send the details to the dev list
18:22:27 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: libvirt: use 'host-passthrough' as default on AArch64 https://review.openstack.org/530965
18:27:17 openstackgerrit Matt Riedemann proposed openstack/nova master: Add regression test for resizing failing when using CachingScheduler https://review.openstack.org/531211
18:27:18 mriedem edleafe: ^ functional regression test for resize + caching scheduler failure
18:29:05 edleafe mriedem: thx
18:29:53 cdent efried: sorry for delay, better ✔
18:30:22 efried Thanks cdent. jaypipes, you want to look before I send it? http://paste.openstack.org/raw/638137/
18:36:48 efried going, going, gone.
18:47:09 cdent shut your filthy mouth efried
18:47:17 cdent (re notifications)
18:47:28 efried Hehehehe, thought you'd like that.
19:02:38 openstackgerrit Merged openstack/nova master: Add support for getting volume details with a specified microversion https://review.openstack.org/529656
19:20:25 openstackgerrit Matt Riedemann proposed openstack/nova master: Handle no allocations during migrate https://review.openstack.org/531220
19:36:08 openstackgerrit Merged openstack/nova master: DriverBlockDevice: make subclasses inherit _proxy_as_attr https://review.openstack.org/524167
19:36:14 openstackgerrit Merged openstack/nova master: Expose BDM uuid to drivers https://review.openstack.org/529037
19:40:36 mriedem mdbooth: i was looking at where _get_volume_config is used and it's used in quite a few places in the libvirt driver, like live migration, swap volume, and generally anywhere we build a guest xml, so also for resize/cold migrate,
19:40:52 mriedem and in a lot of those places, we don't have a volume to know if it's multiattach or not to set the conf.shareable flag,
19:41:19 mriedem so despite it not being great, stashing the multiattach value in the connection_info which gets saved in the bdm is about the best we can do right now
19:41:39 mriedem because all of these places in the driver that call _get_volume_config are using the connection_info off the bdm
19:53:41 sdague mriedem: nice
19:53:58 sdague mriedem: I'd totally believe it, we do extra dumb stuff in there
19:54:11 mriedem substring match is a bit slower, as expected, but still much better than doing it in nova
19:54:17 sdague mriedem: yep
19:54:28 mriedem 4000ms w/o the patch, 400ms with the patch and no substring, about 900ms with the patch and substring match
20:03:37 mriedem cdent: edleafe: it's your favorite game show, "IS IT 400 OR 409?!"
20:04:01 mriedem so, say i'm trying to attach a multiattach volume to an instance and the compute is too old to support multiattach,
20:04:13 mriedem is that a 400, or a 409? knowing that at some point the compute might be upgraded to support multiattach.
20:06:14 cdent the state of the compute is out of sync with the desired state, but you made a valid request (had it been in the right state), so I'd go with 409
20:06:28 mriedem artom: remember how we punted for tagged attached on a shelved offloaded instance because we couldn't tell if the host supported it?
20:06:39 mriedem cdent: ok that's what i was thinking too
20:06:54 cdent \o/
20:07:09 mriedem artom: but we don't make that same distinction in the API for tagged bdms with boot from volume
20:07:17 mriedem can you remember why?
20:08:52 mriedem artom: my guess was "you could reschedule and attempt to hit a host that does support device tagging" but we raise BuildAbortException so we don't even reschedule in that case
20:13:40 openstackgerrit melanie witt proposed openstack/nova master: Add access_url_base to console_auth_tokens table https://review.openstack.org/334614
20:13:40 openstackgerrit melanie witt proposed openstack/nova master: Optionalize instance_uuid in console_auth_token_get_valid() https://review.openstack.org/481700
20:13:41 openstackgerrit melanie witt proposed openstack/nova master: Add ConsoleAuthToken object https://review.openstack.org/320063
20:13:41 openstackgerrit melanie witt proposed openstack/nova master: Add periodic task to clean expired console tokens https://review.openstack.org/325381
20:13:42 openstackgerrit melanie witt proposed openstack/nova master: Use ConsoleAuthToken object to generate authorizations https://review.openstack.org/325414
20:13:42 openstackgerrit melanie witt proposed openstack/nova master: Convert websocketproxy to use db for token validation https://review.openstack.org/333990
20:15:29 edleafe yeah, the request isn't malformed; the system can't support it
20:16:12 artom mriedem, yeah, I think your guess is correct
20:16:14 cdent support it _right now_
20:16:44 mriedem artom: ok, so that's not really any different from punting when trying to attach a volume to a shelved offloaded instance with tags
20:16:58 mriedem artom: i'm only asking b/c we're going to have a similar situation with multiattach volumes
20:17:31 mriedem trying to decide if we should support attaching a multiattach volume to a shelved offloaded instance - same with bfv, either way it might fail once we get to the compute and you're dead
20:18:08 mriedem at some point in the future, which no one will probably ever work on, we could do a scheduler filter for this stuff to make it pick a host which supports the thing you need
20:18:17 artom With the full 100% knowledge of every bit of context about multiattach, I'd vote to be consistent and refuse it for shelved offloaded
20:18:19 mgagne if running mitaka, is legacy v2 API still used or is it dead code?
20:18:39 artom Because we have no idea what host it'll end up on
20:18:43 artom When it's unshelved
20:18:51 mriedem artom: the same is true for boot from volume
20:19:09 artom mriedem, eh, how so?
20:19:13 mriedem but we allow tagged bdms with bfv
20:19:33 mriedem when you create a server, or unshelve a server, they both go through the scheduler to pick a host,
20:19:46 mriedem you have an equal chance in either scenario of picking a host that doesn't support the capability
20:20:05 mriedem so the fact we allow tagged bdms with bfv but not shelved offloaded instances is inconsistent
20:20:12 artom mriedem, how is bfv different from normal volume tagging? IIRC the api just checked service level, to see if the cloud was fully upgraded to support it
20:20:17 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Attach and detach encryptors during swap_volume https://review.openstack.org/531233
20:21:31 mriedem artom: ok yeah that's the one difference then, is that we check in the api when creating a server if the computes are new enough to handle tagged bdms
20:21:43 mriedem we could easily have done the same for shelved offloaded attach
20:22:03 artom mriedem, so there's this 2 x 2 matrix of stuff
20:22:10 artom we have tagged boot / tagged attach
20:22:11 mriedem that's basically what i was saying we'd do in those two cases for multiattach too - check the min compute service version and fail if computes aren't upgraded yet
20:22:20 artom And compute manager supports it / virt driver supports it
20:22:57 artom For tagged boot, we used the service level check to see if compute manager supports it
20:23:12 artom For tagged boot/virt driver... I forget how we handled it
20:23:21 mriedem we just fail in the compute
20:23:24 mriedem and raise BuildAbortException
20:23:50 artom Ah, right, hopefully rescheduling to a virt driver that supports it
20:23:57 mriedem no, we don't reschedule
20:24:09 mriedem BuildAbortException means abort, don't reschedule
20:24:14 artom Ah, ok
20:24:28 artom Yeah, that's not awesome, but no other way of doing it I guess
20:24:31 mriedem BuildRescheduledException means kick edleafe in the head a few times
20:24:43 artom And then for tagged attach...
20:25:05 artom I think they were all RPC calls down to the compute
20:25:13 artom So virt driver support was straightforward
20:25:25 artom Except for shelved offloaded, which was a cast
20:25:28 artom (Obviously)
20:25:28 mriedem yeah that one is easy
20:25:35 mriedem unless the server is shelved offloaded
20:25:42 artom So that one we decided to just fail in the API
20:25:52 mriedem in the case of shelved offloaded, we don't do anything with the compute b/c there is no compute
20:25:58 artom Instead of having the unshelve fail like, 3 years later

Earlier   Later