Posted	Nick	Remark
#openstack-nova - 2019-02-14
18:10:55	efried	Trying to catch up seemed futile, so I'm trying to jump in in the middle, and suffering the consequences.
18:11:03	mriedem	i haven't gone through the comments, but looks like you were expecting us to track vcpu/disk/ram in the request group?
18:11:26	mriedem	we still pull those values off the request_spec.flavor during scheduling prior to calling GET /a_c
18:11:40	efried	mriedem: Yes, I expected that the request spec's list of request groups would contain the request groups.
18:11:48	efried	Not a subset of the request groups
18:12:10	efried	afaict it actually only contains the bw-related rgs.
18:12:22	mriedem	yup
18:12:25	mriedem	it's new as of this series
18:12:37	efried	so like even if you requested a VGPU in a numbered group, and your VCPU in another numbered group, and...
18:12:43	efried	it would still only have the bw groups
18:13:31	efried	it's eventually going to need to contain everything
18:13:52	mriedem	did he put a comment about that in the code or going to document the limitation in a follow up?
18:13:54	efried	or if not "need", it'll soon get to a point where the things that are being excluded won't make any sense.
18:14:25	efried	Well, for someone who has been following along, I'm sure it's not a thang.
18:14:31	efried	But no, he just responded in the comments.
18:14:54	efried	If the rgs member in the request spec was called bandwidth_request_groups, I wouldn't have batted an eye
18:14:56	mriedem	i don't disagree that the 10 roads to get to our GET /a_c is a problem
18:15:02	efried	but then we would have had to change it later
18:15:10	efried	and changing things on an ovo is suck
18:16:06	mriedem	i think it was VGPUs that made me think at one point about how we now have resources we pull from the explicit flavor attributes (ram/vcpu/disk) and VGPU is not a top-level attribute on the flavor, it's an extra_spec
18:16:09	efried	I guess what would help is if RequestSpec.requested_resources had a big NOTE on it saying "currently only houses bandwidth groups"
18:16:29	mriedem	efried: right - that's good for a follow up
18:16:35	mriedem	fup 3 at this point
18:17:30	efried	I'm adding a note.
18:18:17	openstackgerrit	Adrian Chiris proposed openstack/nova master: Libvirt: do not set MAC when unplugging macvtap VF https://review.openstack.org/624842
18:18:17	openstackgerrit	Adrian Chiris proposed openstack/nova master: Add free for claimed, allocated devices https://review.openstack.org/616120
18:18:18	openstackgerrit	Adrian Chiris proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365
18:18:18	openstackgerrit	Adrian Chiris proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929
18:18:19	openstackgerrit	Adrian Chiris proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115
18:18:19	openstackgerrit	Adrian Chiris proposed openstack/nova master: libvirt: auto detach/attach sriov ports on migration https://review.openstack.org/629589
18:18:45	mriedem	like, flavor at this point doesn't even really need to have vcpu/memory_mb/root_gb at top level fields - root_gb=0 was already problematic since people used it to denote volume-backed server flavors
18:19:34	mriedem	which reminds me https://review.openstack.org/#/c/603910/
18:20:56	prometheanfire	is it possible to request the status of pci devices on hypervisors?
18:21:04	prometheanfire	https://wiki.openstack.org/wiki/Pci-api-support#List_and_show_PCI_devices_on_VMs doesn't seem to be used
18:21:20	mriedem	prometheanfire: not in the api
18:22:04	mriedem	prometheanfire: the review for https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/show-server-numa-topology.html talked about that since it was originally munging that in with NUMA topology for a server
18:22:20	mriedem	but that would be allocated pci devices per instance anyway
18:22:31	mriedem	if you're looking for inventory, it has to be retrieved outside of the compute API right now
18:22:43	mriedem	if/when pci device inventory is tracked in placement you'd use the placement API
18:22:57	prometheanfire	ya, placement makes sense
18:23:11	mriedem	oh, and because of the [pci]passthrough_whitelist config option per compute the actual pci devices on the host might not be used by nova
18:23:48	openstackgerrit	Matt Riedemann proposed openstack/nova master: Stub out port binding create/delete in NeutronFixture https://review.openstack.org/636413
18:23:49	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add Migration.cross_cell_move and get_by_uuid https://review.openstack.org/614012
18:23:49	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add Destination.allow_cross_cell_move field https://review.openstack.org/614035
18:23:50	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add InstanceAction/Event create() method https://review.openstack.org/614036
18:23:50	openstackgerrit	Matt Riedemann proposed openstack/nova master: Change HostManager to allow scheduling to other cells https://review.openstack.org/614037
18:23:51	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add CrossCellWeigher https://review.openstack.org/614353
18:23:51	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add Instance.hidden field https://review.openstack.org/631123
18:23:52	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add TargetDBSetupTask https://review.openstack.org/627892
18:23:52	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add CrossCellMigrationTask https://review.openstack.org/631581
18:23:53	openstackgerrit	Matt Riedemann proposed openstack/nova master: Execute TargetDBSetupTask https://review.openstack.org/633853
18:23:53	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add can_connect_volume() compute driver method https://review.openstack.org/621313
18:23:54	openstackgerrit	Matt Riedemann proposed openstack/nova master: WIP: Add prep_snapshot_based_resize_at_dest compute method https://review.openstack.org/633293
18:23:54	openstackgerrit	Matt Riedemann proposed openstack/nova master: WIP: Add PrepResizeAtDestTask https://review.openstack.org/627890
18:23:55	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add prep_snapshot_based_resize_at_source compute method https://review.openstack.org/634832
18:23:55	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add PrepResizeAtSourceTask https://review.openstack.org/627891
18:23:56	openstackgerrit	Matt Riedemann proposed openstack/nova master: WIP: Add finish_snapshot_based_resize_at_dest compute method https://review.openstack.org/635080
18:23:56	openstackgerrit	Matt Riedemann proposed openstack/nova master: Add FinishResizeAtDestTask https://review.openstack.org/635646
18:23:57	openstackgerrit	Matt Riedemann proposed openstack/nova master: Execute CrossCellMigrationTask from MigrationTask https://review.openstack.org/635668
18:27:10	prometheanfire	right, what I want to know is the status/usage of the passthrough_whitelist and alias for the compute hosts
18:27:28	prometheanfire	having that in hv show would be nice
18:28:17	mriedem	throw it in the old train ptg etherpad!
18:28:41	mriedem	but the answer is likely going to be "it will be available in placement (eventually, in a couple of years maybe)"
18:29:11	mriedem	you could write a tool that mines that data from the database....
18:29:20	prometheanfire	meh, not that important
18:29:25	mriedem	the pci_devices table is both inventory and allocations
18:31:31	efried	soon you will be able to query this from the cyborg API :P
18:32:15	efried	using incantations formulated from the charred remains of pci.passthrough_whitelist
18:45:39	openstackgerrit	melanie witt proposed openstack/nova master: Add user_id field to InstanceMapping https://review.openstack.org/633350
18:45:40	openstackgerrit	melanie witt proposed openstack/nova master: Add online data migration for populating user_id https://review.openstack.org/633351
18:52:21	openstackgerrit	melanie witt proposed openstack/nova master: Add user_id column to the instance_mappings table https://review.openstack.org/633349
18:52:21	openstackgerrit	melanie witt proposed openstack/nova master: Add user_id field to InstanceMapping https://review.openstack.org/633350
18:52:22	openstackgerrit	melanie witt proposed openstack/nova master: Add online data migration for populating user_id https://review.openstack.org/633351
19:08:23	openstackgerrit	Merged openstack/nova master: Ensure config regexes match the entire string https://review.openstack.org/636627
19:08:38	openstackgerrit	Merged openstack/nova master: Replace glance command with openstack command https://review.openstack.org/635102
19:08:56	openstackgerrit	Merged openstack/nova master: Switch to using os-resource-classes https://review.openstack.org/628278
19:24:35	openstackgerrit	Merged openstack/nova master: Change live_migration_wait_for_vif_plug=True by default https://review.openstack.org/635360
19:28:04	efried	cdent, jaypipes, gibi, bauzas: I figured out the locking pickle. eventlet.monkey_patch replaces thread with eventlet.green.thread. The former blows up when you try to copy it; the latter does not. And the latter is doing the right thing by creating a new semaphore. http://paste.openstack.org/show/745119/
19:28:07	openstackgerrit	Surya Seetharaman proposed openstack/nova master: API microversion 2.69: Handles Down Cells https://review.openstack.org/591657
19:28:07	openstackgerrit	Surya Seetharaman proposed openstack/nova master: API microversion 2.69: Handles Down Cells Documentation https://review.openstack.org/635147
19:30:57	efried	I also confirmed that, even though they're created with the same key, they are in fact different lock contexts. I.e. I don't deadlock by calling f.acquire() followed by f2.acquire() (but I do deadlock by calling f.acquire() twice).
19:45:51	tomtom001	Hello, I'm running OpenStack Queens and am trying to work with LUKS encryption. My nova-compute node keeps throwing the following error when trying to decrypt the volume: http://paste.openstack.org/show/745122/ - I've verified the code exists under the following path: /openstack/venvs/nova-17.1.2/lib/python2.7/site-packages/castellan/key_manager/barbican_key_manager.py Is there a patch or can
19:45:57	tomtom001	I verify the api_class in the config?
19:55:15	cdent	efried: will you believe me if I said "i thought of that while having dinner"?
19:55:19	cdent	nice sluething
20:05:49	melwitt	tomtom001: where are you configuring the api_class? nova.conf?
20:08:29	tomtom001	melwitt: yes nova.conf api_class = castellan.key_manager.barbican_key_manager.BarbicanKeyManager
20:11:09	efried	cdent: did you really?
20:11:31	efried	I mean, I figured it must be because of a monkey patch somewhere, but I couldn't imagine what/where.
20:11:32	jaypipes	efried: interesting. good sleuthing.
20:16:25	melwitt	tomtom001: ok. I think maybe you aren't supposed to set api_class. see this example config from a gate run in the [key_manager] section http://logs.openstack.org/51/633351/1/check/tempest-full/8473acf/controller/logs/etc/nova/nova_conf.txt.gz
20:16:58	melwitt	[key_manager]/backend = nova.keymgr.conf_key_mgr.ConfKeyManager
20:25:27	melwitt	tomtom001: according to the docs, it looks like you could also use backend='barbican', the api_class setting is deprecated https://docs.openstack.org/nova/queens/configuration/config.html?highlight=fixed_key#key_manager.backend
20:25:57	tomtom001	melwitt: thanks I'll check it out
20:33:39	tomtom001	melwitt: looks to me like it doesn't support rbd yet. http://paste.openstack.org/show/745124/ Also, I can't instantiate the other one. Weird. That backend may only work for a fixed key as well.
20:33:49	tomtom001	melwitt: what do you think?
20:35:54	melwitt	lyarwood is the best person to answer that but he's in EU time zone and off by now, so let me look through the feature patches quickly. I didn't remember rbd being excluded
20:39:55	melwitt	the commit message mentions rbd, implying it should work https://review.openstack.org/523958 but I don't know more than that, unfortunately
20:40:39	melwitt	but that error is coming from os-brick. going to see when that was added
20:41:02	melwitt	oh, wait, that's because it's falling back on the old, non-native encryption in your case

Earlier   Later