Open Stack

Hi everyone,

A potential issue regarding naming has come up during review of the 
ephemeral storage encryption feature [1][2] patch series [3] and we're 
looking for input before moving forward with any naming/terminology 
changes across the specs and the entire patch series.

The concern that has been raised is around use of the term "ephemeral" 
for the name of this feature including traits, extra specs, and image 
properties [4].

For context, the objective of this feature is to provide users with the 
ability to specify that all local disks for the instance be encrypted. 
This includes the root disk and any other local disks.

The initial concern is around use of the word "ephemeral" for the root disk.

My general interpretation of the word "ephemeral" for storage in nova 
has been that it means attached storage that only persists for the 
lifetime of the instance and is destroyed if and when the instance is 
destroyed. This is in contrast to attached cinder volumes which can 
persist after instance deletion.

But should "ephemeral" ever be used to describe a root disk? Is it 
incorrect and/or ambiguous to refer to it as such?

This is part of what is being discussed in [4].

During discussion, I also realized there is a separate gap in the above 
interpretation of "ephemeral" in nova. When cinder volumes are attached 
to an instance, their persistence after the instance is deleted depends 
on whether the 'delete_on_termination' attribute is set to true in the 
request payload when the instance is created [5] or when attaching a 
volume to the instance [6] or updating a volume attached to the instance 
[7].

This means that in the currently proposed patches, if a user specifies 
hw:ephemeral_encryption in the extra_specs, for example, and they also 
have a volume with delete_on_termination=True attached, only the root 
disk will be encrypted via the extra spec -- the volume would not be 
encrypted. Encryption of the volume has to be requested in cinder.

Could this mislead a user into thinking both the root disk and cinder 
volume are encrypted when only the root disk is?

Because of the above issues, we are considering whether we should change 
the terminology used in this feature at this stage. Some ideas include 
"local encryption", "local disk encryption", "disk encryption". IMHO 
"disk_encryption" is ambiguous in its own way because an attached cinder 
volume also has a disk.

Changing the naming will be a non-trivial amount of work, so we wanted 
to get additional input before going ahead with such a change.

Another thing noted in a comment on another patch in the series [8] is 
that the os-traits for this feature have already been merged [9]. If we 
decide to change the naming, should we go ahead and use these traits 
as-is and have them not match the naming in nova or should we deprecate 
them and add new traits that match the new name and use those?

I hope this makes sense and your input would be much appreciated.

Cheers,
-melwitt

[1] 
https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/ephemeral-storage-encryption.html
[2] 
https://specs.openstack.org/openstack/nova-specs/specs/yoga/approved/ephemeral-encryption-libvirt.html
[3] 
https://review.opendev.org/q/topic:specs%252Fyoga%252Fapproved%252Fephemeral-encryption-libvirt
[4] 
https://review.opendev.org/c/openstack/nova/+/764486/10/nova/api/validation/extra_specs/hw.py#516
[5] 
https://docs.openstack.org/api-ref/compute/?expanded=create-server-detail#create-server
[6] 
https://docs.openstack.org/api-ref/compute/?expanded=attach-a-volume-to-an-instance-detail
[7] 
https://docs.openstack.org/api-ref/compute/?expanded=update-a-volume-attachment-detail
[8] 
https://review.opendev.org/c/openstack/nova/+/760456/10/nova/scheduler/request_filter.py#425
[9] 
https://github.com/openstack/os-traits/blob/f64d50e4dd2f21558fb73dd4b59cd1d4b121b707/os_traits/compute/ephemeral.py