| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-03-08 | |||
| 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 | |
| 13:09:20 | jrosser | ok before i check that, i had another thing with hw_rescue_bus=scsi | |
| 13:09:27 | lyarwood | is there the original boot element higher in the XML? | |
| 13:09:44 | jrosser | in the instance console bus=scsi gives "no bootable device" | |
| 13:14:13 | jrosser | lyarwood: i've just redone it with the bus=usb http://paste.openstack.org/show/803378/ | |
| 13:14:44 | sean-k-mooney | lyarwood: we dont really suppor t mixing buses properly | |
| 13:14:59 | sean-k-mooney | i dont think we generate the contoler properly in all cases | |
| 13:15:41 | lyarwood | sean-k-mooney: the instance was already using SCSI in the bus=scsi case so that should work | |
| 13:16:00 | lyarwood | sean-k-mooney: and bus=usb worked for me while I was testing this back in the day with virtio disks attached | |
| 13:16:21 | sean-k-mooney | yep but i thik we have some edge cases with scsi and virtio blk | |
| 13:16:50 | lyarwood | yeah | |
| 13:17:05 | sean-k-mooney | usb would likely have worked because the usb contoler was previously always added by libvirt | |
| 13:17:25 | sean-k-mooney | i have seen issue where the scsi contoler was not alwasy added but that might have been fixed by now | |
| 13:17:33 | lyarwood | jrosser: just building an env now to play with this | |
| 13:18:19 | jrosser | lyarwood: oh cool, thankyou :) | |
| 13:18:31 | lyarwood | jrosser: oh wait, does this reproduce if you use a different image? | |
| 13:18:49 | jrosser | i can try that | |
| 13:19:18 | lyarwood | yeah please, it might be the rescue disk is finding the original disk first and mounting it as the root filesystem as the labels match | |
| 13:19:49 | lyarwood | so we are booted into the kernel from the rescue disk using the filesystem from the original | |
| 13:20:38 | jrosser | also somewhat contrary to the stuff right at the end of here, leaving --image off does some fail-y thing i've not yet found https://docs.openstack.org/nova/latest/user/rescue.html | |
| 13:22:07 | lyarwood | hmm with a boot from volume instance it should try to boot from the original image referenced by the volume, if one is present. I forget what the behaviour is if an image wasn't used to create the volume. | |
| 13:24:46 | jrosser | from the wording i'd inferred that no --image would make it use the 'default', i.e the one from the instance being rescued | |
| 13:28:00 | sean-k-mooney | do we support rescue for BFV | |