| opendevreview | Nobuhiro MIKI proposed openstack/nova master: libvirt: Support maxphysaddr. https://review.opendev.org/c/openstack/nova/+/907516 | 03:56 |
|---|---|---|
| *** dasm is now known as Guest1011 | 04:31 | |
| *** Guest1011 is now known as dasm | 04:31 | |
| LarsErikP | elodilles: aha! We are working on upgrading from yoga anyway, so I guess we will be good ;) | 07:37 |
| LarsErikP | sean-k-mooney: thanks for the explanation =) We definitly has count_usage_from_placement | 07:42 |
| LarsErikP | jamespage: woho \o/ we will help verify the nova-package at <3 | 07:42 |
| LarsErikP | at least* | 07:42 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: trivial doc fix https://review.opendev.org/c/openstack/nova/+/901237 | 07:59 |
| opendevreview | Merged openstack/nova master: trivial doc fix https://review.opendev.org/c/openstack/nova/+/901237 | 08:33 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Fix trivial doc issues https://review.opendev.org/c/openstack/nova/+/878779 | 09:14 |
| *** tosky_ is now known as tosky | 09:40 | |
| opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Fix device type when booting from ISO image https://review.opendev.org/c/openstack/nova/+/909611 | 11:04 |
| sean-k-mooney | bauzas: rajesh has respon https://review.opendev.org/c/openstack/nova/+/904568 can you re review and if your happy with it ill try and review it later | 13:25 |
| bauzas | ack | 13:25 |
| sean-k-mooney | amit adresses my issues with https://review.opendev.org/c/openstack/nova/+/901824 too so that just needs a second core to review | 13:26 |
| sean-k-mooney | i updated the etherpad with that info | 13:26 |
| sean-k-mooney | im hesitent to merge anytrhing that conflcits with the encyption series but those should hopefully be small | 13:27 |
| *** haleyb|out is now known as haleyb | 14:22 | |
| bauzas | sean-k-mooney: I'll review amit's rfe shortly but I started reviewing mel's patches and I struggle understanding what she did tbh | 14:34 |
| bauzas | I don't feel confident about providing +2s for things so tangled | 14:34 |
| bauzas | and that I'm not an expert | 14:34 |
| bauzas | so I can try to give it a shot but it will be more based on your own expertise and mel's evidences of that it works | 14:35 |
| dansmith | melwitt: sean-k-mooney: where's the job add/change for this in the stack? | 16:55 |
| dansmith | (for ephemeral encryption) | 16:56 |
| melwitt | dansmith: this is what I've been using https://review.opendev.org/c/openstack/nova/+/862416 it changes the default flavors for tempest to ones that request encryption and then runs all of normal tempest with that | 16:57 |
| dansmith | melwitt: thanks | 16:57 |
| dansmith | melwitt: so are we going to change over one/more jobs to use these? | 16:58 |
| dansmith | melwitt: and the failed run on that needs a recheck I assume | 16:59 |
| melwitt | dansmith: yeah I'm not sure what consensus would want to do here. sean-k-mooney and I chatted about the possibility of adding "smoke" style tests in tempest to do a very basic thing. another option is using something like what's in the DNM and run it periodic because of how heavy they are | 16:59 |
| dansmith | or potentially add a compute feature flag to tempest to just run a few tests with flavors asking for it? | 17:00 |
| melwitt | dansmith: yeah, that's an unrelated fail that needs a recheck. I'll do that | 17:01 |
| melwitt | dansmith: yeah that would be another option | 17:01 |
| melwitt | I had the recheck in a draft comment and hadn't posted it 😣 | 17:17 |
| sean-k-mooney | dansmith: ya so i would liek to add a couple of simple test behind a compute_feature flag in tempest | 17:23 |
| sean-k-mooney | dansmith: melwitt has the every weithg job that turns this on in the flavor for all the tempest vms | 17:24 |
| sean-k-mooney | which we could do in a perodic but not every patch due to the time it takes | 17:24 |
| dansmith | the what? | 17:24 |
| sean-k-mooney | heavy weight | 17:24 |
| sean-k-mooney | the dnm test just changes the tempest flvoars to make all vms use encyption | 17:25 |
| sean-k-mooney | but since the flavor has ephmeral root and swap | 17:25 |
| sean-k-mooney | it slows down the job | 17:25 |
| sean-k-mooney | if we dont already have a job with barbican i would ike to have at least one so we can test cinder volume encyption and vtpm in that job too | 17:26 |
| sean-k-mooney | i have not checked if we have any job today with barbican in our gate | 17:26 |
| melwitt | I think we don't, so that's kind of the main thing is how do we want to add barbican | 17:29 |
| melwitt | add it to an existing job like nova-next and then set a feature flag to run limited encryption tests? | 17:30 |
| dansmith | yeah, something | 17:30 |
| dansmith | or maybe nova-lvm since it's kinda relatedish? | 17:31 |
| sean-k-mooney | not really since this feature wont support lvm | 17:31 |
| sean-k-mooney | at least not in this release | 17:31 |
| dansmith | meaning we can't do this underneath an lvm-backed nova? | 17:31 |
| dansmith | I meant it's related to a more complex ephemeral disk layout | 17:32 |
| sean-k-mooney | correct the serise is currently for qcow, raw and rbd | 17:32 |
| sean-k-mooney | lvm could be supproted but not in the current serise | 17:32 |
| dansmith | and we fail in that scenario how? | 17:32 |
| sean-k-mooney | it does not report the triat saying we supprot this | 17:32 |
| 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 |
| dansmith | okay so if you have all LVM-backed nodes and you ask for this, nothing will be bootable | 17:33 |
| sean-k-mooney | there is a per image backend SUPPORTS_LUKS flag | 17:33 |
| sean-k-mooney | correct | 17:33 |
| sean-k-mooney | if we assume this is enabeld in the falvor rahter then the imge | 17:34 |
| sean-k-mooney | the presence of an encypted flavor tells you the operator has configured an approate backedn | 17:35 |
| sean-k-mooney | (or they think they have) | 17:35 |
| sean-k-mooney | but as an end user you cant tell form the api if this will work without trying it | 17:35 |
| sean-k-mooney | i.e. if you wanted to enabel it in the image | 17:35 |
| dansmith | there's a comment in one of the files that says otherwise | 17:35 |
| dansmith | which I asked if it was correct | 17:35 |
| 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 |
| sean-k-mooney | you can use the old epmeral encyption feature in the lvm backend | 17:36 |
| sean-k-mooney | but i belive that is config file based and not flavor/image based | 17:37 |
| melwitt | yeah the existing ephemeral encryption is for the lvm backend only and it works via config options | 17:39 |
| dansmith | so the comment is wrong yeah? | 17:45 |
| 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 |
| dansmith | is that not the case? | 17:46 |
| melwitt | sorry, which comment? | 17:47 |
| dansmith | one of my comments on the second patch | 17:49 |
| dansmith | about a comment in the code that says the user can request a format | 17:49 |
| 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:51 |
| dansmith | okay but fast clone can't be used here either right? | 17:52 |
| 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 |
| 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 |
| 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 |
| dansmith | okay that's not quite "the user" for a flavor, but will that be honored from an image? | 17:53 |
| sean-k-mooney | flatening the image for rbd | 17:54 |
| sean-k-mooney | yes | 17:54 |
| dansmith | and qcow/ | 17:54 |
| sean-k-mooney | qcow could share backing files for the same user on the same host | 17:55 |
| dansmith | but not from a public image right? | 17:55 |
| melwitt | fast clone would be for taking snapshots | 17:55 |
| sean-k-mooney | and if the base qcow is not encypted we can share the backing file as normal | 17:55 |
| sean-k-mooney | dansmith: mels serise supprot taking a non encypted qcow and then creating an encypted root disk | 17:56 |
| dansmith | by flattening or does qemu handle only writing the delta as encrypted? | 17:56 |
| melwitt | yes there is hw_ephemeral_encryption_format as an image property as wel | 17:57 |
| dansmith | melwitt: ack, just seems a bit too behind-the-curtain to me | 17:57 |
| 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:57 |
| dansmith | that's okay for flavor, but wrong for image (and user-controllable to me).. | 17:58 |
| sean-k-mooney | i belvie we create a seperate encypted backing file but reuse the image cache to copy the data | 17:58 |
| sean-k-mooney | i would have to check again | 17:58 |
| bauzas | folks, that discussion seems highly important for me to understand all of the meat, but I need to end my day :( | 17:58 |
| bauzas | make sure I'll read the logs tomorrow when I'm back and crazy enough to start reviewing again | 17:59 |
| dansmith | sean-k-mooney: okay I was expecting you can't mix those two things.. | 17:59 |
| 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 |
| melwitt | (near the end of the series encrypted backing file support is added for qcow2) | 17:59 |
| dansmith | perhaps you can and qemu only encrypts the delta, but I kinda expected it was all or nothing | 17:59 |
| dansmith | melwitt: right, but with different keys? | 17:59 |
| melwitt | dansmith: the backing file will be the same key, the deltas will all be different keys | 18:00 |
| 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:00 |
| melwitt | dansmith: yes you can | 18:01 |
| 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 |
| dansmith | melwitt: okay, in the libvirt xml? | 18:01 |
| melwitt | dansmith: yes | 18:01 |
| 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 |
| melwitt | there is a backingStore xml element which can have a <encryption> element under it | 18:01 |
| dansmith | ah, okay, cool | 18:02 |
| melwitt | yeah, you don't have to tell me lol ... it's all pretty much undocumented so figuring that out was fun | 18:02 |
| dansmith | ack | 18:02 |
| dansmith | yeah I literally don't see it in the libvirt docs | 18:03 |
| melwitt | I learned a lot from old bugzillas I found with google. there might be one example somewhere in the docs, checking | 18:04 |
| dansmith | "Note that the 'qcow' format of encryption is broken" | 18:04 |
| dansmith | does that mean qcow and not qcow2? | 18:04 |
| dansmith | oh, they mean qcow encryption not encryption with qcow I think | 18:05 |
| 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 |
| melwitt | unless maybe you're reading a different doc than the qemu ones | 18:05 |
| dansmith | boy, yeah I don't see any example of multiple layers of encryption | 18:06 |
| dansmith | but, when you put the backingstore in there, the deepest one is the lowest layer in the stack it looks like | 18:07 |
| melwitt | this is what it looks like without encryption https://libvirt.org/kbase/backing_chains.html#advanced-backing-chain-specifications | 18:07 |
| melwitt | and encryption is really just sticking the <encryption> element under each backingStore if that layer is encrypted | 18:07 |
| dansmith | aha yeah | 18:08 |
| dansmith | and presumably if a layer doesn't have an <enc> then it's cleartext and not inherited from the parent ... | 18:08 |
| melwitt | thankfully we're only dealing with two layers | 18:09 |
| dansmith | yeah | 18:09 |
| melwitt | this is one of the bugzillas I used to learn it https://bugzilla.redhat.com/show_bug.cgi?id=1788898 | 18:09 |
| melwitt | yeah, that's my understanding | 18:10 |
| dansmith | melwitt: I assume you're in the middle of replying to my comments on that second patch right? | 18:10 |
| dansmith | I'm specifically interested in the key reuse one, since that seems like a -1 | 18:11 |
| sean-k-mooney | yeah net split is over? | 18:11 |
| melwitt | yes | 18:11 |
| dansmith | cool, thanks | 18:11 |
| opendevreview | Merged openstack/nova master: Catch ImageNotFound on snapshot failure https://review.opendev.org/c/openstack/nova/+/905316 | 20:59 |
| opendevreview | melanie witt proposed openstack/nova master: DNM test ephemeral encryption + resize: qcow2, raw, rbd https://review.opendev.org/c/openstack/nova/+/862416 | 21:25 |
| dansmith | melwitt: sorry :/ | 21:45 |
| melwitt | haha np | 21:46 |
| -opendevstatus- NOTICE: Gerrit on review.opendev.org will be restarted to perform a minor upgrade to the service. | 22:34 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!