Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-07-26
17:32:59 sean-k-mooney they might not alwasy be type local
17:33:03 dansmith that's the proposed title of the feature/spec?
17:33:22 bauzas dansmith: I said earlier, I'm terrible at naming
17:33:28 bauzas I'm just quite giving up
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

Earlier   Later