Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-05-20
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 melwitt "today" meaning in the proposed patch series?
17:54:15 sean-k-mooney i might be mixing that up with signed images
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?
18:01:27 sean-k-mooney can you elaberate?
18:01:30 dansmith you want them to set that property on an encrypted image they upload just in case someone wants to boot from it?
18:01:43 sean-k-mooney no
18:01:56 dansmith because if they don't you'll decrypt their data when you boot from it if you don't know to go set that intent flag
18:02:03 sean-k-mooney but if we were taking a snapshot of a BFV volume we could
18:02:07 melwitt I think that's where I differ in my thought, I don't think hw_ephemeral_encryption (the boolean) on the snapshot. only the secret uuid (os_glance_encrypt_key_id) which implies it is encrypted
18:02:27 sean-k-mooney it imples the image is
18:02:39 sean-k-mooney but not that only encypted guest can be crated form it
18:03:06 melwitt right
18:03:24 sean-k-mooney weither we set hw_ephemeral_encyption on the snapshot is a design choose we can make
18:03:53 sean-k-mooney but to me hw_ephemeral_encyption is the only thing on an image that says the resulting vm must be booted with encypted local storage
18:04:01 dansmith melwitt: wait, you think that if you snapshot an encrypted instance to an encrypted image and then create another instance from that, it should be de-crypted?
18:05:17 melwitt dansmith: no, I don't.. but somewhere along code review someone commented that I should not assume encrypted if the source is encrypted. originally I did assume encrypted if source encrypted
18:05:29 gmann sean-k-mooney: yes, we can use the "files" (files is correct name of var, not relevent-files ) variable to define the files we want to run the job when they are changed.
18:05:44 dansmith okay, I missed that I guess.. I definitely do not think we should ever decrypt unless specifically asked
18:06:13 sean-k-mooney dansmith: so to me that means we shoudl reject booting form an image with OS_GLACE_* options
18:06:17 dansmith so if we have the hw_ boolean on the image, I think that either we take the default to match the format, or we *require* it be set to something before we agree to use the image (i.e. tell me what you want me to do with this)

Earlier   Later