| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-08 | |||
| 19:40:27 | artom | I guess not, but I think I'm confident enough in my thinking that I'll go ahead | |
| 19:40:43 | artom | Replied in review, in any case | |
| 19:49:53 | sean-k-mooney | stephenfin: replied on the port policy spec. bauzas suggested i check for the extenion to be extra safe so dont really want to remove it unless he is ok with it | |
| 20:19:29 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: pci manager: replace node_id parameter with compute_node https://review.opendev.org/c/openstack/nova/+/778747 | |
| 20:19:30 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: pci: implement the 'socket' NUMA affinity policy https://review.opendev.org/c/openstack/nova/+/772779 | |
| 20:19:30 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: pci: track host NUMA topology in stats https://review.opendev.org/c/openstack/nova/+/774149 | |
| 20:57:20 | melwitt | lyarwood: fyi https://review.opendev.org/c/openstack/nova/+/777218 and https://review.opendev.org/c/openstack/nova/+/777219 are ready for review on stable/ussuri. there are two more patches under them (sorry!) that I included bc (1) it's a bug fix I had forgotten to backport and (2) they eliminate merge conflicts | |
| 21:30:31 | openstackgerrit | sean mooney proposed openstack/nova master: add vdpa nodedev parsing and interface config gen https://review.opendev.org/c/openstack/nova/+/770532 | |
| 21:30:31 | openstackgerrit | sean mooney proposed openstack/nova master: add constants for vnic type vdpa https://review.opendev.org/c/openstack/nova/+/770474 | |
| 21:30:32 | openstackgerrit | sean mooney proposed openstack/nova master: extend pci dev_type for vdpa https://review.opendev.org/c/openstack/nova/+/777481 | |
| 21:30:33 | openstackgerrit | sean mooney proposed openstack/nova master: add vdpa device detection https://review.opendev.org/c/openstack/nova/+/770533 | |
| 21:30:34 | openstackgerrit | sean mooney proposed openstack/nova master: add hw:mlock extra spec https://review.opendev.org/c/openstack/nova/+/778347 | |
| 21:30:35 | openstackgerrit | sean mooney proposed openstack/nova master: add vdpa vnic to pci request mapping and filtering. https://review.opendev.org/c/openstack/nova/+/778350 | |
| 21:32:34 | openstackgerrit | sean mooney proposed openstack/nova master: add vdpa nodedev parsing and interface config gen https://review.opendev.org/c/openstack/nova/+/770532 | |
| 21:32:34 | openstackgerrit | sean mooney proposed openstack/nova master: add hw:mlock extra spec https://review.opendev.org/c/openstack/nova/+/778347 | |
| 21:32:35 | openstackgerrit | sean mooney proposed openstack/nova master: add vdpa device detection https://review.opendev.org/c/openstack/nova/+/770533 | |
| 21:32:35 | openstackgerrit | sean mooney proposed openstack/nova master: extend pci dev_type for vdpa https://review.opendev.org/c/openstack/nova/+/777481 | |
| 21:32:36 | openstackgerrit | sean mooney proposed openstack/nova master: add vdpa vnic to pci request mapping and filtering. https://review.opendev.org/c/openstack/nova/+/778350 | |
| 21:49:17 | openstackgerrit | Ghanshyam proposed openstack/nova master: Change default policy for GET '/os-hypervisors' API https://review.opendev.org/c/openstack/nova/+/765798 | |
| 21:51:38 | openstackgerrit | Ghanshyam proposed openstack/nova master: Change default policy for GET '/os-hypervisors' API https://review.opendev.org/c/openstack/nova/+/765798 | |
| 22:19:39 | openstackgerrit | Merged openstack/nova master: libvirt: Add tests for insecure UEFI configuration https://review.opendev.org/c/openstack/nova/+/777367 | |
| 23:05:15 | openstackgerrit | sean mooney proposed openstack/nova master: Support per port numa policies with SR-IOV https://review.opendev.org/c/openstack/nova/+/773792 | |
| 23:05:51 | openstackgerrit | sean mooney proposed openstack/nova master: Support per port numa policies with SR-IOV https://review.opendev.org/c/openstack/nova/+/773792 | |
| #openstack-nova - 2021-03-09 | |||
| 01:17:59 | yonglihe | gibi: thanks raise the VIC TYPE concerns, I tested by wire that in local repo. I try to verify Rodolfo's patch today: https://review.opendev.org/c/openstack/neutron/+/779292 | |
| 01:31:11 | gmann | stephenfin: gibi updated the policy patch for modernize-os-hypervisors-api BP https://review.opendev.org/c/openstack/nova/+/765798/5 | |
| 08:52:40 | yonglihe | gibi: alex_xu:, F.Y.I I've talke with ralonsoh and slaweq, that neutron patch is likely merged today: https://review.opendev.org/c/openstack/neutron/+/779292 | |
| 09:01:11 | lyarwood | melwitt: ack np looking | |
| 09:04:19 | lyarwood | elod: https://review.opendev.org/c/openstack/nova/+/777217/ - I think you forgot to vote on this? | |
| 09:20:34 | elod | lyarwood: wow. apparently. thx. :S | |
| 09:20:56 | lyarwood | elod: np I've done that lots with the new UI | |
| 09:22:15 | elod | yeah, let's blame that o:) I don't know how i missed to vote :S sorry :S | |
| 09:48:41 | stephenfin | oh, no Gerrit bot? | |
| 09:48:56 | stephenfin | trivial fix to address some issues coming down the pipeline with setuptools here https://review.opendev.org/c/openstack/nova/+/779449 | |
| 09:52:22 | jrosser | could i get some help with this when debugging why i can't rescue boot-from-volume images https://opendev.org/openstack/nova/src/branch/master/nova/api/openstack/compute/rescue.py#L60 | |
| 09:53:32 | jrosser | if i print req.api_version_request i get "API Version Request Major: 2, Minor: 1" | |
| 09:53:54 | jrosser | that seems always going to fail if passed to api_version_request.is_supported(req, '2.87') | |
| 09:55:08 | stephenfin | jrosser: How are you making the request/ | |
| 09:57:12 | jrosser | stephenfin: either through horizon or `openstack server rescue --image 14600a9b-a240-4210-8a32-cea43d0499ac 4f2b0a96-7b6b-4d01-bb75-1248574e71d6` | |
| 09:57:32 | stephenfin | you need to request API microversion 2.87, as that code would suggest | |
| 09:57:44 | stephenfin | openstack --os-compute-api-version 2.87 server rescue ... | |
| 09:57:49 | stephenfin | should do the trick | |
| 09:58:00 | stephenfin | OSC currently defaults to 2.1. We're working on fixing that | |
| 09:58:16 | stephenfin | I don't know how to do the equivalent in Horizon | |
| 09:58:22 | jrosser | ooooohhhh - well thats explains it! | |
| 09:59:24 | jrosser | perhaps that warrants a docs fix here https://docs.openstack.org/nova/latest/user/rescue.html | |
| 09:59:47 | stephenfin | Yes, good point | |
| 09:59:58 | stephenfin | lyarwood: Maybe if you have time in the next few weeks? ^ | |
| 10:11:14 | jawad_axd | d.Any comments on this?Thanks | |
| 10:11:14 | jawad_axd | Hi folks, how luks password is generated for instance booted from encrypted volume? Barbican is used in environment. I can grab luks password like “virsh secret-get-value SECRET-UUID | —base64 —decode” when instance is running on compute node. How can I generate this password on my own? Use case is: if instance is backed up outside somewhere and needs to boot standalone, thus needs luks passwor | |
| 10:15:06 | jrosser | jawad_axd: there was a thread on the mailing list about this recently http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020374.html | |
| 10:17:29 | jawad_axd | @jrosser I missed that one. I look into it. Thanks | |
| 10:21:53 | lyarwood | stephenfin: sorry was afk, reading | |
| 10:23:30 | lyarwood | huh how did I miss that | |
| 10:32:02 | lyarwood | stephenfin: https://review.opendev.org/c/openstack/nova/+/779479 | |
| 10:32:17 | lyarwood | jawad_axd: hey sorry reading | |
| 10:33:20 | lyarwood | jawad_axd: yeah that post on the ML spells out how to grab the passphrase from the key manager, it's awful I know but thanks to design choices made before my time :/ | |
| 10:34:22 | lyarwood | jawad_axd: http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020421.html specifically lists the steps | |
| 10:42:00 | jawad_axd | @lyarwood Thanks. Apparently, it requires volume to to be mapped. I am wondering if there is an easy way to decrypt/decode it from barbican cli, when encrypted volume exists in environment and is in in AVAILABLE state.a | |
| 10:44:35 | lyarwood | jawad_axd: No, you can't stream/decode an unmapped encrypted volume. | |
| 10:45:03 | lyarwood | jawad_axd: unlike Glance, Cinder doesn't send actual volume data via the API | |
| 10:45:28 | lyarwood | jawad_axd: so you will need to map the encrypted volume to a host before being able to decrypt it | |
| 10:46:27 | lyarwood | jawad_axd: as the owner of the volume you could snapshot it and download the encrypted volume snapshot from glance I guess | |
| 10:46:44 | lyarwood | jawad_axd: that would give you a local file you could then decrypt but it's not the live volume | |
| 10:47:11 | gibi | stephenfin: question in https://review.opendev.org/c/openstack/nova/+/779449/1/setup.cfg#11 | |
| 10:57:00 | jawad_axd | @lyarwood Ok.. if I understand correctly, luks header is attached to 'rbd disk in my case' when we create instance from encrypted volume, is that right ? My understanding is, when we create encrypted volume from image, it attaches luks header to volume_from_image that time, if its true then it should be possible to retrieve luks password when it is not mapped. | |
| 10:59:32 | lyarwood | jawad_axd: the header is always attached but the actual passphrase is stored outside of that in the key manager and doesn't require access to the volume or image | |
| 11:01:00 | lyarwood | jawad_axd: to be clear, fetching the passphrase and decrypting data are two seperate steps | |
| 11:01:14 | lyarwood | jawad_axd: you don't need access to the volume to fetch the passphrase from the key manager | |
| 11:01:37 | lyarwood | jawad_axd: you do need access to the volume or a downloaded image to decrypt the actual data held within them | |
| 11:02:29 | jawad_axd | @lyarwood I am actually concerned about passphrase here. How to get it from key manager.. I | |
| 11:03:03 | lyarwood | jawad_axd: kk then it's this part | |
| 11:03:13 | lyarwood | openstack secret get --payload_content_type 'application/octet-stream' http://192.168.122.208/key-manager/v1/secrets/6fd4f879-005d-4b7d-9e5f-2505f010be7c --file mysecret.key | |
| 11:03:37 | lyarwood | jawad_axd: ^ where the URL is provided by `openstack secret list` and lists your secret UUID | |
| 11:04:25 | lyarwood | ah yeah it does | |
| 11:04:28 | lyarwood | https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=show-a-volume-s-details-detail#show-a-volume-s-details | |
| 11:04:39 | lyarwood | if you do an `openstack volume show $volume` | |
| 11:04:46 | lyarwood | encryption_key_id is the secret uuid | |
| 11:05:27 | lyarwood | jawad_axd: `hexdump -e '16/1 "%02x"' mysecret.key` will then give you the passphrase used to unlock the LUKS header | |
| 11:05:39 | lyarwood | which is awful | |
| 11:05:41 | lyarwood | but here we are | |
| 11:06:45 | lyarwood | jawad_axd: FWIW by default only the owner of the volume should have access to this secret | |
| 11:12:08 | jawad_axd | @lyarwood Yesss... I just tested and got passphrase from "hexdump -e '16/1 "%02x"' mysecret.key" . Very cool. Thanks alot. | |
| 12:50:02 | stephenfin | gibi: Done | |
| 12:52:41 | jrosser | stephenfin: thankyou for the api version tip before, i am now able to put a boot-from-volume instance into rescue | |
| 12:52:52 | stephenfin | hth | |
| 12:53:02 | jrosser | it doesnt quite behave as i expect though :) | |
| 12:53:17 | jrosser | i seem to get the original instance root disk as the root disk in the rescue instance | |
| 12:54:01 | jrosser | this is the xml i get for the disks http://paste.openstack.org/show/803376/ | |
| 13:05:25 | lyarwood | jrosser: yup that's by design, it's using stable device rescue so the original disks are presented first | |
| 13:05:33 | lyarwood | jrosser: with the rescue disk last | |
| 13:06:01 | jrosser | but i would expect it to boot off the USB disk in that case? | |
| 13:06:18 | lyarwood | jrosser: note the boot order element, it boots from the rescue disk | |
| 13:06:35 | gibi | stephenfin: thanks +2 | |
| 13:06:51 | jrosser | yeah, so with hw_rescue_bus=usb i don't see it boot from the usb device | |
| 13:07:06 | lyarwood | jrosser: is it the same image in the volume and rescue image? | |
| 13:07:28 | jrosser | it should be, +/- the snapshots in the ceph backend | |
| 13:07:55 | lyarwood | jrosser: right so are you sure it's booting from the original volume? | |
| 13:08:04 | lyarwood | this caught be out a few times while testing this | |
| 13:08:48 | jrosser | yes, its confusing, one moment | |
| 13:09:10 | lyarwood | hmm actually I wonder if this is a valid bug when using a different bus | |