| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-02-25 | |||
| 21:25:43 | opendevreview | Jay Faulkner proposed openstack/nova master: Limit nodes by ironic shard key https://review.opendev.org/c/openstack/nova/+/903915 | |
| 21:25:44 | opendevreview | Jay Faulkner proposed openstack/nova master: Add nova-manage ironic-compute-node-move https://review.opendev.org/c/openstack/nova/+/903916 | |
| 21:25:44 | opendevreview | Jay Faulkner proposed openstack/nova master: Make compute node rebalance safer https://review.opendev.org/c/openstack/nova/+/903917 | |
| #openstack-nova - 2024-02-26 | |||
| 03:56:49 | opendevreview | Nobuhiro MIKI proposed openstack/nova master: libvirt: Support maxphysaddr. https://review.opendev.org/c/openstack/nova/+/907516 | |
| 07:37:59 | LarsErikP | elodilles: aha! We are working on upgrading from yoga anyway, so I guess we will be good ;) | |
| 07:42:07 | LarsErikP | sean-k-mooney: thanks for the explanation =) We definitly has count_usage_from_placement | |
| 07:42:29 | LarsErikP | jamespage: woho \o/ we will help verify the nova-package at <3 | |
| 07:42:34 | LarsErikP | at least* | |
| 07:59:30 | opendevreview | Rajesh Tailor proposed openstack/nova master: trivial doc fix https://review.opendev.org/c/openstack/nova/+/901237 | |
| 08:33:31 | opendevreview | Merged openstack/nova master: trivial doc fix https://review.opendev.org/c/openstack/nova/+/901237 | |
| 09:14:33 | opendevreview | Rajesh Tailor proposed openstack/nova master: Fix trivial doc issues https://review.opendev.org/c/openstack/nova/+/878779 | |
| 11:04:01 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Fix device type when booting from ISO image https://review.opendev.org/c/openstack/nova/+/909611 | |
| 13:25:10 | 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:25 | bauzas | ack | |
| 13:26:23 | 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:32 | sean-k-mooney | i updated the etherpad with that info | |
| 13:27:31 | sean-k-mooney | im hesitent to merge anytrhing that conflcits with the encyption series but those should hopefully be small | |
| 14:34:10 | 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:31 | bauzas | I don't feel confident about providing +2s for things so tangled | |
| 14:34:40 | bauzas | and that I'm not an expert | |
| 14:35:19 | 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 | |
| 16:55:57 | dansmith | melwitt: sean-k-mooney: where's the job add/change for this in the stack? | |
| 16:56:19 | dansmith | (for ephemeral encryption) | |
| 16:57:10 | 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:24 | dansmith | melwitt: thanks | |
| 16:58:02 | dansmith | melwitt: so are we going to change over one/more jobs to use these? | |
| 16:59:20 | dansmith | melwitt: and the failed run on that needs a recheck I assume | |
| 16:59:55 | 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 | |
| 17:00:34 | dansmith | or potentially add a compute feature flag to tempest to just run a few tests with flavors asking for it? | |
| 17:01:21 | melwitt | dansmith: yeah, that's an unrelated fail that needs a recheck. I'll do that | |
| 17:01:34 | melwitt | dansmith: yeah that would be another option | |
| 17:17:08 | melwitt | I had the recheck in a draft comment and hadn't posted it 😣 | |
| 17:23:36 | sean-k-mooney | dansmith: ya so i would liek to add a couple of simple test behind a compute_feature flag in tempest | |
| 17:24:09 | sean-k-mooney | dansmith: melwitt has the every weithg job that turns this on in the flavor for all the tempest vms | |
| 17:24:22 | sean-k-mooney | which we could do in a perodic but not every patch due to the time it takes | |
| 17:24:31 | dansmith | the what? | |
| 17:24:51 | sean-k-mooney | heavy weight | |
| 17:25:05 | sean-k-mooney | the dnm test just changes the tempest flvoars to make all vms use encyption | |
| 17:25:20 | sean-k-mooney | but since the flavor has ephmeral root and swap | |
| 17:25:26 | sean-k-mooney | it slows down the job | |
| 17:26:05 | 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:21 | sean-k-mooney | i have not checked if we have any job today with barbican in our gate | |
| 17:29:23 | melwitt | I think we don't, so that's kind of the main thing is how do we want to add barbican | |
| 17:30:45 | melwitt | add it to an existing job like nova-next and then set a feature flag to run limited encryption tests? | |
| 17:30:59 | dansmith | yeah, something | |
| 17:31:09 | dansmith | or maybe nova-lvm since it's kinda relatedish? | |
| 17:31:36 | sean-k-mooney | not really since this feature wont support lvm | |
| 17:31:40 | sean-k-mooney | at least not in this release | |
| 17:31:56 | dansmith | meaning we can't do this underneath an lvm-backed nova? | |
| 17:32:15 | dansmith | I meant it's related to a more complex ephemeral disk layout | |
| 17:32:20 | sean-k-mooney | correct the serise is currently for qcow, raw and rbd | |
| 17:32:33 | sean-k-mooney | lvm could be supproted but not in the current serise | |
| 17:32:47 | dansmith | and we fail in that scenario how? | |
| 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 | 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 | |