| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-02-26 | |||
| 17:32:59 | sean-k-mooney | it does not report the triat saying we supprot this | |
| 17:33:21 | sean-k-mooney | so an lvm cloud will have no valid host or select a non lvm node if they eexist and supprot it | |
| 17:33:34 | dansmith | okay so if you have all LVM-backed nodes and you ask for this, nothing will be bootable | |
| 17:33:44 | sean-k-mooney | there is a per image backend SUPPORTS_LUKS flag | |
| 17:33:56 | sean-k-mooney | correct | |
| 17:34:52 | sean-k-mooney | if we assume this is enabeld in the falvor rahter then the imge | |
| 17:35:12 | sean-k-mooney | the presence of an encypted flavor tells you the operator has configured an approate backedn | |
| 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 | dansmith | there's a comment in one of the files that says otherwise | |
| 17:35:46 | sean-k-mooney | i.e. if you wanted to enabel it in the image | |
| 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 would have to check again | |
| 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: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 | melwitt | yes | |
| 18:11:14 | sean-k-mooney | yeah net split is over? | |
| 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 | https://docs.openstack.org/nova/2023.2/install/compute-install-ubuntu.html | |
| 06:15:32 | mohsen | https://docs.openstack.org/nova/2023.2/install/controller-install-ubuntu.html | |
| 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 | 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: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 | |