| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-26 | |||
| 17:33:57 | dansmith | I think the problem is, things were named, and then we implemented lots of features that blurred all the lines we had, which makes not only the existing names less than ideal, but also makes it hard to accurately describe what we're talking about | |
| 17:34:07 | dansmith | which pretty much means there's hardly any point in a rename of anything, IMHO | |
| 17:34:11 | bauzas | this feature is about to encrypt BDMs which are local | |
| 17:34:23 | bauzas | hence the countername | |
| 17:34:28 | dansmith | "non-volume data disks" is probably the most accurate, but I mean, good lord :) | |
| 17:34:30 | sean-k-mooney | bauzas: it also works for ceph volumes allocated by nova | |
| 17:34:34 | sean-k-mooney | so local is not really right | |
| 17:34:35 | dansmith | bauzas: not always local :) | |
| 17:34:45 | sean-k-mooney | its about encypting non cinder sotrage | |
| 17:35:05 | melwitt | swap isn't included so "non-volume data disks" doesn't even work :P | |
| 17:35:11 | sean-k-mooney | although personally i woudl have perfered if it also work for bfv | |
| 17:35:26 | sean-k-mooney | melwitt: very true | |
| 17:35:49 | dansmith | melwitt: but swap isn't encrypted right? that's why I put "data" in there :) | |
| 17:36:14 | sean-k-mooney | dansmith: what would the flavor extra specs be for that | |
| 17:36:27 | melwitt | ephemeral_and_root_disk_encryption 😂 | |
| 17:36:37 | dansmith | nvdd_encryption=FML | |
| 17:36:40 | melwitt | dansmith: oh, I see. yeah swap is not encrypted | |
| 17:36:50 | melwitt | I didn't get the "data" emphasis | |
| 17:36:53 | sean-k-mooney | honestly i prefer that name to what we have | |
| 17:37:35 | sean-k-mooney | too bad we cant just call it nova_disk_encryption | |
| 17:37:43 | sean-k-mooney | i.e. encyuption for stuff nova owns | |
| 17:38:22 | dansmith | non-volume is the key I think, but it's not very nice to say/write | |
| 17:38:48 | sean-k-mooney | ya | |
| 17:39:03 | sean-k-mooney | flavor_disk_encryption? | |
| 17:39:07 | sean-k-mooney | but no | |
| 17:39:10 | sean-k-mooney | that break for bfv | |
| 17:39:24 | sean-k-mooney | well sort of | |
| 17:39:41 | melwitt | and swap | |
| 17:39:51 | dansmith | the argument here is about the naming of the extra spec? | |
| 17:39:53 | sean-k-mooney | ya swap i would honestly just add | |
| 17:39:59 | dansmith | I mean to be honest, this feels like a *massive* waste of time | |
| 17:40:04 | sean-k-mooney | dansmith: yes extra spec and image property | |
| 17:40:23 | dansmith | how about nova_disk_encryption <- excludes cinder, and if you're worried about swap, then add swap to it and move on | |
| 17:40:39 | sean-k-mooney | i would be happy with ^ | |
| 17:41:05 | bauzas | wfm | |
| 17:41:06 | sean-k-mooney | i just was not sure if we are ment to use the project name in things like this | |
| 17:41:28 | bauzas | let's just write a very good config option doc | |
| 17:41:46 | dansmith | nova_ on this case makes it clear we're talking about the things nova owns | |
| 17:41:52 | sean-k-mooney | sure and by config option doc you mean flavor validator doc | |
| 17:41:52 | dansmith | compute_ would work too I guess, but I think it's less clear | |
| 17:42:28 | sean-k-mooney | ack ya nova_ i liek more but i would be happy with compute_ | |
| 17:42:40 | sean-k-mooney | so either i think are ok | |
| 17:42:53 | dansmith | nova_ and promise to never ever discuss this again? :) | |
| 17:43:16 | bauzas | or say it 5 times in front of a mirror ? | |
| 17:43:24 | sean-k-mooney | :) | |
| 17:43:38 | sean-k-mooney | melwitt: are you ok with that? | |
| 17:45:06 | melwitt | I guess. I'm focused on making sure everyone's happy with the name. I checked https://docs.openstack.org/glance/latest/admin/useful-image-properties.html and don't find any other project names there so that feels a bit weird, but ¯\_(ツ)_/¯ | |
| 17:45:45 | bauzas | virt_disk_encryption ? | |
| 17:45:57 | dansmith | intrinsic_disk_encryption, managed_disk_encryption | |
| 17:46:00 | bauzas | damn, I stepped into the ... | |
| 17:46:15 | dansmith | virt_ is not specific enough I think, because cinder disks aren't real disks | |
| 17:46:30 | dansmith | non_volume_disk_encryption.. uglier, but no project name and more accurate | |
| 17:46:42 | dansmith | OR | |
| 17:46:52 | bauzas | oh, I was poorly refering to the fact we defer the disk creation to the underlying virt driver | |
| 17:46:55 | dansmith | we explain that "ephemeral disks" are "everything but volume disks" and then we're back to the start! | |
| 17:47:08 | melwitt | 😂 ahhhhhh | |
| 17:47:29 | sean-k-mooney | ya i still fine ephmeral kind of insulting to refer to novas storage but thats just me | |
| 17:47:30 | bauzas | (18:57:19) bauzas: yeah, if we need to write some doc explaining "ephemeral" == "this new thing" this is bad | |
| 17:47:30 | bauzas | (18:56:47) bauzas: if we pick something else, this has to be better understandable about what it is | |
| 17:47:30 | bauzas | (18:57:39) bauzas: hence the challenge | |
| 17:48:19 | dansmith | sean-k-mooney: you're fine or you "find" ? | |
| 17:48:35 | bauzas | cores, would appreciate a quick +2 on os-vif blocking https://review.opendev.org/c/openstack/nova/+/850998/2 | |
| 17:48:35 | sean-k-mooney | we have had customer go to great lents to do terible things because they found the term ephemeral unackceptable | |
| 17:48:44 | sean-k-mooney | dansmith: i find | |
| 17:48:54 | bauzas | or because they considered hostnames be FQDNs ? | |
| 17:49:03 | bauzas | sorry, this was easy | |
| 17:49:11 | sean-k-mooney | bauzas: we should not need that anymore | |
| 17:49:14 | dansmith | personally I think ephemeral is a pretty accurate name | |
| 17:49:17 | sean-k-mooney | bauzas: its blocked in upperconstraits | |
| 17:49:28 | dansmith | if they're local disks on compute nodes, then ephemeral means "they could go away if a single computer dies" | |
| 17:49:43 | sean-k-mooney | yep and so could cinder volumes | |
| 17:49:48 | dansmith | and even when they're on ceph, they're treated not nearly as precious as data volumes | |
| 17:49:49 | sean-k-mooney | dansmith: most of them dont provide ha | |
| 17:49:59 | bauzas | sean-k-mooney: we're pulling u-c on all jobs ? | |
| 17:50:04 | dansmith | sean-k-mooney: but the intent behind a volume is long-term storage generally | |
| 17:50:10 | sean-k-mooney | bauzas: we shoudl be | |
| 17:50:12 | bauzas | I thought this was only on tox targets | |
| 17:50:19 | bauzas | and not tempest | |
| 17:50:21 | sean-k-mooney | bauzas: it would be a bug if we were not | |
| 17:50:26 | melwitt | sean-k-mooney: what's the customer did something bad bc they didn't like the term? | |
| 17:50:50 | opendevreview | Stephen Finucane proposed openstack/nova master: hacking: force explicit import of python's mock https://review.opendev.org/c/openstack/nova/+/708768 | |
| 17:51:10 | sean-k-mooney | well i wont mention there name but they instead on doing pci passthough fo a raid controler intor ther vm because they did not accept novas ephmeral storage as accpetable | |
| 17:51:10 | bauzas | sean-k-mooney: I'll propose a new rev for https://review.opendev.org/c/openstack/nova/+/838976, we'll see | |
| 17:52:23 | dansmith | sean-k-mooney: but that's just because either they didn't read docs, understand, or our docs suck | |
| 17:53:08 | dansmith | and if they're making decisions based on their perception of one word without knowing what it means in context, then they probably have many other problems | |
| 17:53:22 | sean-k-mooney | dansmith: yes they messed up the server toplogy and didnt realise we did not supprot block deivce passethough other then via cinder | |
| 17:53:23 | dansmith | like thinking cinder volumes are actually burnt ashes of former disks | |
| 17:53:35 | dansmith | and nova computes explode to make new space clouds | |
| 17:55:09 | melwitt | lol @ burnt former disks | |
| 17:56:39 | sean-k-mooney | i think im to the point where i dont care anymore | |
| 17:57:59 | dansmith | well, jokes aside, I think we probably have to just pick something that won't be perfect and move on | |
| #openstack-nova - 2022-07-27 | |||
| 06:10:53 | opendevreview | melanie witt proposed openstack/nova master: imagebackend: Add support to libvirt_info for LUKS based encryption https://review.opendev.org/c/openstack/nova/+/826755 | |
| 06:49:43 | gibi | o/ | |
| 07:00:28 | opendevreview | Takashi Natsume proposed openstack/nova-specs master: Create specs directory for 2023.1 Antelope https://review.opendev.org/c/openstack/nova-specs/+/851007 | |
| 07:25:58 | bauzas | \o | |
| 07:42:39 | gibi | bauzas: I left feedback in https://review.opendev.org/c/openstack/nova/+/838976 | |
| 08:11:05 | bauzas | gibi: will look soon | |
| 09:02:12 | opendevreview | wangkuntian proposed openstack/nova master: Modify the url of openstack client commands. https://review.opendev.org/c/openstack/nova/+/851197 | |
| 09:39:52 | gibi | stephenfin, sean-k-mooney: we have valid py310 failures in the mock switch patch | |
| 09:41:12 | gibi | we can debate that py310 is non voting, so we can merge regardless but as the failure is valid we just pushing the problem to our future slef | |