Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-02-26
17:35:17 sean-k-mooney (or they think they have)
17:35:29 sean-k-mooney but as an end user you cant tell form the api if this will work without trying it
17:35:46 sean-k-mooney i.e. if you wanted to enabel it in the image
17:35:46 dansmith there's a comment in one of the files that says otherwise
17:35:53 dansmith which I asked if it was correct
17:36:19 dansmith made it sound like you could request this via the block device or something, but I haven't gotten that far up the stack to know if that's true or not
17:36:22 sean-k-mooney you can use the old epmeral encyption feature in the lvm backend
17:37:13 sean-k-mooney but i belive that is config file based and not flavor/image based
17:39:55 melwitt yeah the existing ephemeral encryption is for the lvm backend only and it works via config options
17:45:32 dansmith so the comment is wrong yeah?
17:46:17 dansmith also, I'm sure ceph has some inbuilt encryption stuff right? I would assume luks encryption on top of rbd would be almost not-production-quality poor in terms of performance
17:46:24 dansmith is that not the case?
17:47:49 melwitt sorry, which comment?
17:49:04 dansmith one of my comments on the second patch
17:49:10 dansmith about a comment in the code that says the user can request a format
17:51:19 melwitt there is some inbuilt encryption stuff in ceph but as of the current stable release Quincy it doesn't support fast clone of encrypted disks and having a passphrase that's different than the parent. so there's a release note (on the rbd backend patch) stating that. for the performance, I would not be surprised if people wouldn't want to use it given the absence of fast clone. but I wasn't sure if it should be left out entirely bc of that
17:52:34 dansmith okay but fast clone can't be used here either right?
17:53:11 melwitt oh, yeah there's the flavor extra spec hw:ephemeral_encryption_format which is the only way to request a format but currently we're not supporting anything other than 'luks'
17:53:13 dansmith in fact, I'm not even sure how you could go from a non-encrypted base image to a root disk that uses encryption with this unless we flatten it when we create the instance
17:53:30 sean-k-mooney i honestly would not really think luks vs not logs would matter too much to rbd. its providing a block laywer device we are jsut creating a luks partion on that block device
17:53:50 dansmith okay that's not quite "the user" for a flavor, but will that be honored from an image?
17:54:38 sean-k-mooney flatening the image for rbd
17:54:45 sean-k-mooney yes
17:54:58 dansmith and qcow/
17:55:26 sean-k-mooney qcow could share backing files for the same user on the same host
17:55:36 dansmith but not from a public image right?
17:55:37 melwitt fast clone would be for taking snapshots
17:55:50 sean-k-mooney and if the base qcow is not encypted we can share the backing file as normal
17:56:32 sean-k-mooney dansmith: mels serise supprot taking a non encypted qcow and then creating an encypted root disk
17:56:58 dansmith by flattening or does qemu handle only writing the delta as encrypted?
17:57:11 melwitt yes there is hw_ephemeral_encryption_format as an image property as wel
17:57:32 dansmith melwitt: ack, just seems a bit too behind-the-curtain to me
17:57:58 dansmith melwitt: that's not asking for anything that will affect the hardware in the guest (like numa or something), but rather only controls what is happening under the covers
17:58:20 dansmith that's okay for flavor, but wrong for image (and user-controllable to me)..
17:58:42 sean-k-mooney i belvie we create a seperate encypted backing file but reuse the image cache to copy the data
17:58:42 sean-k-mooney i would have to check again
17:58:49 bauzas folks, that discussion seems highly important for me to understand all of the meat, but I need to end my day :(
17:59:08 bauzas make sure I'll read the logs tomorrow when I'm back and crazy enough to start reviewing again
17:59:11 dansmith sean-k-mooney: okay I was expecting you can't mix those two things..
17:59:18 melwitt it can also take encrypted qcow and share an encrypted backing file. otherwise in something like taking a snapshot of an encrypted instance and then booting other instances from that snapshot, you would have to make a copy of the encrypted backing file which would make it not cow
17:59:36 melwitt (near the end of the series encrypted backing file support is added for qcow2)
17:59:39 dansmith perhaps you can and qemu only encrypts the delta, but I kinda expected it was all or nothing
17:59:57 dansmith melwitt: right, but with different keys?
18:00:15 melwitt dansmith: the backing file will be the same key, the deltas will all be different keys
18:00:57 dansmith melwitt: okay so you can configure a key per layer? I'm not sure how that works because you tell libvirt "here's my qcow disk" and that disk references the base image,
18:01:11 melwitt dansmith: yes you can
18:01:15 dansmith so unless you stash the key for the base image in the delta/snapshot disk, I'm not sure how libvirt/qemu would know
18:01:22 dansmith melwitt: okay, in the libvirt xml?
18:01:32 melwitt dansmith: yes
18:01:48 dansmith okay, normally you don't have to tell libvirt about the base layers, so I've never seen what that looks like
18:01:54 melwitt there is a backingStore xml element which can have a <encryption> element under it
18:02:02 dansmith ah, okay, cool
18:02:18 melwitt yeah, you don't have to tell me lol ... it's all pretty much undocumented so figuring that out was fun
18:02:27 dansmith ack
18:03:25 dansmith yeah I literally don't see it in the libvirt docs
18:04:01 melwitt I learned a lot from old bugzillas I found with google. there might be one example somewhere in the docs, checking
18:04:03 dansmith "Note that the 'qcow' format of encryption is broken"
18:04:09 dansmith does that mean qcow and not qcow2?
18:05:10 dansmith oh, they mean qcow encryption not encryption with qcow I think
18:05:12 melwitt that is a different encryption (I know, helpful). it means the original legacy implementation of encryption in qemu. which was replaced with the new one that is being used in the series now
18:05:55 melwitt unless maybe you're reading a different doc than the qemu ones
18:06:05 dansmith boy, yeah I don't see any example of multiple layers of encryption
18:07:13 dansmith but, when you put the backingstore in there, the deepest one is the lowest layer in the stack it looks like
18:07:24 melwitt this is what it looks like without encryption https://libvirt.org/kbase/backing_chains.html#advanced-backing-chain-specifications
18:07:55 melwitt and encryption is really just sticking the <encryption> element under each backingStore if that layer is encrypted
18:08:29 dansmith aha yeah
18:08:59 dansmith and presumably if a layer doesn't have an <enc> then it's cleartext and not inherited from the parent ...
18:09:08 melwitt thankfully we're only dealing with two layers
18:09:13 dansmith yeah
18:09:49 melwitt this is one of the bugzillas I used to learn it https://bugzilla.redhat.com/show_bug.cgi?id=1788898
18:10:15 melwitt yeah, that's my understanding
18:10:26 dansmith melwitt: I assume you're in the middle of replying to my comments on that second patch right?
18:11:13 dansmith I'm specifically interested in the key reuse one, since that seems like a -1
18:11:14 sean-k-mooney yeah net split is over?
18:11:14 melwitt yes
18:11:23 dansmith cool, thanks
20:59:59 opendevreview Merged openstack/nova master: Catch ImageNotFound on snapshot failure https://review.opendev.org/c/openstack/nova/+/905316
21:25:34 opendevreview melanie witt proposed openstack/nova master: DNM test ephemeral encryption + resize: qcow2, raw, rbd https://review.opendev.org/c/openstack/nova/+/862416
21:45:35 dansmith melwitt: sorry :/
21:46:41 melwitt haha np
#openstack-nova - 2024-02-27
05:17:58 opendevreview Nobuhiro MIKI proposed openstack/nova master: libvirt: Support maxphysaddr. https://review.opendev.org/c/openstack/nova/+/907516
06:10:59 mohsen https://www.irccloud.com/pastebin/277NPQbS/
06:15:32 mohsen Hello dear friends. I wanted to report a misconfiguration in the official documentation of OpenStack nova. I put the link at the end of this message.
06:15:32 mohsen In the [service_user] section, they should place the port number of keystone which is 5000 but it has been mistakenly omitted and caused a lot of trouble and error during the installation procedure of the nova on both controller and compute node.
06:15:32 mohsen https://docs.openstack.org/nova/2023.2/install/controller-install-ubuntu.html
06:15:32 mohsen https://docs.openstack.org/nova/2023.2/install/compute-install-ubuntu.html
06:31:53 opendevreview Rajesh Tailor proposed openstack/nova master: Fix trivial doc issues https://review.opendev.org/c/openstack/nova/+/878779
10:59:22 bauzas sean-k-mooney: can you please swing https://review.opendev.org/c/openstack/nova/+/907516 again ,
10:59:24 bauzas ?
11:05:56 opendevreview sean mooney proposed openstack/nova master: [DNM] poc nova-ironic shard job https://review.opendev.org/c/openstack/nova/+/910333
11:06:06 sean-k-mooney bauzas: sure
11:06:39 sean-k-mooney i saw it come in but wanted to wait for you to see if your happy
11:08:18 sean-k-mooney bauzas: based on the delta form v3 it looks ok to me
11:10:30 opendevreview sean mooney proposed openstack/nova master: [DNM] poc nova-ironic shard job https://review.opendev.org/c/openstack/nova/+/910333
12:33:32 auniyal hi bauzas, regarding comment "LOG.info(_("foo %s", something))" on sonsole patch - on using "_(" pre-commit says - N319 Don't translate logs
12:34:38 auniyal and with fstring in logs we get like this https://paste.opendev.org/show/bM1D6nY1sxuHibnpHEax/
12:57:41 sean-k-mooney auniyal: yes just remove _( )
12:57:56 sean-k-mooney LOG.info("foo %s", something)
12:58:34 auniyal ack
12:58:44 auniyal sean-k-mooney, regarding other 2 comments ?

Earlier   Later