| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-05-20 | |||
| 12:11:58 | sean-k-mooney | the simplest possibel fix in this case would be ot catch the excption to record the instance action and log/ignore it then proceeed with the delete | |
| 12:13:29 | sean-k-mooney | that would be a valid resolution to the bug but if the instance does not exist in the cell db it also means we cant mark it as deleted which means we have no way to interup the request to spawn it. | |
| 12:13:42 | sean-k-mooney | which is why this is a hard thing to fix as a first bug | |
| 12:15:29 | wncslln | I see... I'll follow the bug updates to see the resolution and try to understand it | |
| 12:16:29 | wncslln | so sean-k-mooney, do you recommend any bug? | |
| 12:17:06 | sean-k-mooney | we do actully have a list of low hanging fruit bugs https://bugs.launchpad.net/nova/+bugs?field.tag=low-hanging-fruit i have not looked at that in a while | |
| 12:17:11 | sean-k-mooney | but perhaps one of those | |
| 12:18:31 | sean-k-mooney | perhaps https://bugs.launchpad.net/nova/+bug/2015330 | |
| 12:19:40 | sean-k-mooney | for something perhaps more featury then bug we have this tech debt reduction bug https://bugs.launchpad.net/nova/+bug/1994139 | |
| 12:22:57 | wncslln | I'll take a look on these. thanks! | |
| 13:36:36 | stan | live migrate says rolled back on the target server, what would be the appropriate logs to check for further troubleshooting? | |
| 14:36:29 | opendevreview | sean mooney proposed openstack/nova master: [WIP] ensure correct cleanup of multi-attach volumes https://review.opendev.org/c/openstack/nova/+/916322 | |
| 14:52:12 | dansmith | bauzas: trivial patches to CI jobs, if you have a minute: https://review.opendev.org/c/openstack/nova/+/919738 | |
| 14:52:33 | dansmith | first one saves us *minutes* of setup time on the affected jobs, second one goes back to regular images as we discussed | |
| 15:24:22 | opendevreview | Dan Smith proposed openstack/nova master: Stop using split UEC image (mostly) https://review.opendev.org/c/openstack/nova/+/919739 | |
| 15:24:22 | opendevreview | Dan Smith proposed openstack/nova master: Enable OCaaS for several nova jobs https://review.opendev.org/c/openstack/nova/+/919738 | |
| 15:24:28 | dansmith | melwitt: ^ | |
| 15:24:35 | dansmith | good catch! | |
| 15:32:58 | dansmith | melwitt: thanks! | |
| 15:33:38 | melwitt | np | |
| 15:46:25 | sean-k-mooney | dansmith: looks like we have upgraded the version of zuul? | |
| 15:46:48 | sean-k-mooney | The RE2 syntax error is: invalid perl operator: (?! | |
| 15:47:23 | sean-k-mooney | clarkb: i rember ther was an annouchment about that a while ago but nova was not using any non RE2 regexes at the time | |
| 15:47:29 | sean-k-mooney | and i dont think we have added any since | |
| 15:47:50 | sean-k-mooney | clarkb: any idea why we are seeing https://review.opendev.org/c/openstack/nova/+/919738/1..2/.zuul.yaml#336 now | |
| 15:48:41 | sean-k-mooney | clarkb: is this just a warning currently? | |
| 15:50:43 | sean-k-mooney | looks like negitive matches are now triggering it | |
| 15:50:46 | sean-k-mooney | irrelevant-files: | |
| 15:50:48 | sean-k-mooney | - ^(?!.zuul.yaml)(?!nova/virt/libvirt/)(?!nova/privsep/).*$ | |
| 15:51:19 | sean-k-mooney | i belive what we are trying to express in the nova-lvm jobs is | |
| 15:51:53 | sean-k-mooney | we should only run this on changes to .zuul.yaml nova/virt/libvirt/** and nova/privsep/** | |
| 15:52:25 | sean-k-mooney | so the way to fix this would be to use relevant-files: instead right? | |
| 15:52:30 | sean-k-mooney | gmann: ^ | |
| 15:58:53 | sean-k-mooney | so relevent-files: "^(?:.zuul\.yaml|nova\/virt\/libvirt\/.*|nova\/privsep\/.*)$" | |
| 17:40:48 | sean-k-mooney | dansmith: melwitt am i correct that your preference is to move forward with https://review.opendev.org/c/openstack/nova-specs/+/907654 and then continue the converstaion in the implemenation review and loop back and update the spec if needed | |
| 17:41:25 | dansmith | I think I said as much, but I wasn't anticipating your most recent concern, so if we need to nail that down, we should | |
| 17:42:25 | sean-k-mooney | my main concenr is ensuring tha we can express if the instance is encypted (and optionally the format) and if the image is encypted (and the format) seperatly | |
| 17:42:48 | dansmith | yeah I know, and as I just noted, I think that's a dangerous tripwire :) | |
| 17:43:39 | sean-k-mooney | why so? the format so the image and root disk may not be the same. | |
| 17:44:17 | sean-k-mooney | are you suggesting that we shoudl require the instance to be encypted if the image is | |
| 17:44:52 | dansmith | yes and especially that we should not *decrypt* the image if you boot from it without that requirement | |
| 17:45:15 | sean-k-mooney | so i see that as being in conflict with allowing you to take an unecypted snapshot | |
| 17:45:19 | dansmith | that's kinda like having FDE enabled and dropping it because you upgraded to the next version of your OS and forgot to opt-in again | |
| 17:45:42 | dansmith | why? you're specifically asking to have it de-crypted in that case | |
| 17:45:59 | sean-k-mooney | and you explcitly ask to not encypt the instance in the other | |
| 17:46:05 | sean-k-mooney | well implictly | |
| 17:46:16 | dansmith | very implicitly :) | |
| 17:46:17 | sean-k-mooney | but unless we make it a tristate | |
| 17:46:25 | sean-k-mooney | i think that equivlent | |
| 17:46:58 | dansmith | well, the other option would be to require your hw_ to be set to either match the format of the image, or explicitly request cleartext and we refuse to boot if it's not set to match | |
| 17:47:08 | dansmith | but I think that's just adding an extra hoop for people | |
| 17:47:38 | sean-k-mooney | well i wasd thinking that you might want to upload the image in gpg format to glance | |
| 17:47:47 | sean-k-mooney | but boot form a vm in luks format | |
| 17:47:58 | melwitt | I thought the debate here is whether or not to allow a change in encryption format going from image => root disk. because otherwise afaict hw:ephemeral_encryption (the bool) provides everything else? | |
| 17:48:03 | sean-k-mooney | after all we cant boot form an image in gpg format right | |
| 17:48:11 | dansmith | as I said in my reply, I think this is getting to the point of unnecessary layers that users don't care about (i.e. the distinction between glance and nova and cinder's notion of the encrypted-ness) | |
| 17:49:11 | dansmith | sean-k-mooney: gpg format is useless.. it was added before and only because there wasn't userspace tooling for LUKS | |
| 17:49:22 | dansmith | I think they're mostly using it as an example at this point and I thought they were going to drop that anyway | |
| 17:49:31 | sean-k-mooney | ok but we cant boot form that | |
| 17:49:36 | dansmith | correct | |
| 17:50:08 | sean-k-mooney | we could boot form it if we decypt or convert | |
| 17:50:19 | dansmith | melwitt: one or more of us is implying too much about the format of the image and the intent for booting new instances I guess.. the boolean doesn't really matter, it's the default we assume | |
| 17:51:03 | sean-k-mooney | well the bool is ment to be (should this instance have encypted ephemeral storage) | |
| 17:51:28 | dansmith | my concerns are that (a) we should never implicitly decrypt something and (b) we should not design something that requires us to do a (very expensive) format/encryption conversion for the usual case | |
| 17:51:29 | sean-k-mooney | that is indepenent of if its BFV or boot form image | |
| 17:52:20 | sean-k-mooney | well the only way to avoid the format conversion would be luks iamge and luks encyption for qemu | |
| 17:52:48 | sean-k-mooney | we cant store dmcypt_plain images in glance can we? | |
| 17:52:55 | sean-k-mooney | if we can that woudl also be valid | |
| 17:53:10 | melwitt | I agree we should never implicitly decrypt something | |
| 17:53:26 | sean-k-mooney | cant we boot form encypted iamges today? | |
| 17:53:34 | sean-k-mooney | i tought we always decypted them? | |
| 17:53:46 | dansmith | eh? | |
| 17:53:48 | sean-k-mooney | maybe thats not a thing? | |
| 17:54:13 | melwitt | (don't want any surprises) | |
| 17:54:15 | sean-k-mooney | i might be mixing that up with signed images | |
| 17:54:15 | melwitt | "today" meaning in the proposed patch series? | |
| 17:54:22 | melwitt | in the series there is support for booting from encrypted images | |
| 17:54:28 | melwitt | oh, yeah you might be thinking of signed | |
| 17:54:29 | sean-k-mooney | no today meaning Caracal/master | |
| 17:54:34 | dansmith | that's kinda the whole point right? | |
| 17:54:46 | dansmith | (booting from encrypted images" | |
| 17:55:38 | sean-k-mooney | not entirely. so i tought the gap we were trying to solve is booting vms with encypted local storage | |
| 17:55:52 | sean-k-mooney | irriespective of the encyption state in glance | |
| 17:56:14 | melwitt | I think the main point is booting encrypted from unencrypted but booting from encrypted quickly becomes an expectation bc of snapshotting imho | |
| 17:56:16 | dansmith | what's the point of local storage encryption if snapshots are clear? | |
| 17:56:36 | sean-k-mooney | they wernt clear in the previosu iteration of the spec | |
| 17:56:53 | dansmith | maybe I'm completely off base here, but in a cloud snapshots are like the #2 most important unit of measure behind instances themselves | |
| 17:56:55 | melwitt | because the user might add private data after that (I thought?) | |
| 17:56:59 | dansmith | you need snaps for basically everything in the cloud workflow | |
| 17:57:16 | sean-k-mooney | i dont think that is true | |
| 17:57:28 | melwitt | but like for example my laptop, the OS image was not encrypted but my disk is encrypted | |
| 17:58:11 | sean-k-mooney | * i dont think snapshots is the #2 most imporant thing in a cloud workflow | |
| 17:58:16 | dansmith | melwitt: it's a bit different there because the OS is read-only and your user data is transportable separately from the OS image, whereas we don't really support that | |
| 17:58:27 | melwitt | that's what I think the most common case probably is. but like I said I think if snapshot is a basic feature available in the cloud, I think users would expect to be able to boot from an encrypted snapshot as well | |
| 17:58:29 | dansmith | sean-k-mooney: okay well, we disagree there then | |
| 17:59:25 | sean-k-mooney | melwitt: right but lest take an example | |
| 17:59:45 | sean-k-mooney | i boot a vm form an unencypted ubuntu image with a flavor that enabel instance encyption | |
| 18:00:18 | sean-k-mooney | if we take a snapshot of that then i would expect you to set the hw_ephemeral_encyption image property in the snapshot | |
| 18:00:35 | sean-k-mooney | and the OS_GLACE_* properties to recored the format | |
| 18:01:14 | dansmith | what about cinder? | |