| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-14 | |||
| 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 | |
| 20:42:09 | melwitt | only the native luks encryption through qemu will work with rbd | |
| 20:42:39 | tomtom001 | melwitt: I'm struggling to find how to set that up. Do you know? | |
| 20:43:44 | tomtom001 | melwitt: or at least docs on how to? | |
| 20:44:40 | melwitt | yeah, there's not a special doc because it's mostly automatic. the release notes describe what versions of qemu and libvirt are required for it to use native encryption https://docs.openstack.org/releasenotes/nova/queens.html | |
| 20:46:39 | melwitt | there, in the "New Features" section is some info about it. for example, if you have instances using encryption prior to queens, you need to reboot them (maybe hard reboot) to get them to generate new xml needed to do the native encryption. or live migrate them between queens compute hosts | |