consider volume_services_id instead of volume_id on #182

[glimchb]

see #182 (comment)

[benlwalker]

I don't feel like that makes any sense. It's a reference to the volume resource, not some sideband service. Can we elaborate on the thinking here?

[glimchb]

I just didn't want to loose a comment from @jainvipin here #182 (comment)
not sure I get it myself, so will let @jainvipin to elaborate

[jainvipin]

@glimchb @benlwalker - my thought was that middle-end objects specifies a set of service applied to a given namespace/volume. Saying that this is a volume reference is not reflecting that this is a middle end object that is identifying a set of services (e.g. crypto) applied on a given volume. May be there is a better word to capture that but certainly leaving it as volume will be confusing, because it doesn't refer to the volume.

[glimchb]

I was thinking like in linux kernel...

you have block device, on top you can add crypto and result is still block device...
you add RAID and result is still block device...

so instead of block we calling this here volume.

apply crypto and new volume is created with crypto
apply compression and new volume is created...

thoughts ?

[benlwalker]

The way most block storage stacks work (Windows, Linux, SPDK, etc.) is by building IO pipelines consisting of a stack of "block devices". The block devices have types (NVMe, SCSI, crypto, raid). Some block devices represent physical storage. Some block devices represent remote storage. Some block devices are purely virtual and can only be layered on top of other block devices (crypto, raid).

OPI is simply using this long established model and calling the objects that get stacked "volumes". To build a volume that does inline encryption of data, you'd layer a CryptoVolume on top of an NVMeVolume, for example. You assign the top-level volume_id into a subsystem when you create a namespace.

Note also that the stacks do not need to be linear. RAID would aggregate, a partition splits, etc. That's why each layer has to return their own new volume(s).

[glimchb]

@benlwalker this leads to a question I had - create call can return a list of objects ?

[benlwalker]

It could, but more likely what'll happen for the partition/logical volume case is you'll call an API to provision some sort of "manager" object, associated with a backing volume. Then you'd ask the manager to provision volumes for you, giving you one volume_id at a time. That's because other than very simple splitting, the creation and destruction of volumes is dynamic and on-going.

[jainvipin]

The way most block storage stacks work (Windows, Linux, SPDK, etc.) is by building IO pipelines consisting of a stack of "block devices". The block devices have types (NVMe, SCSI, crypto, raid). Some block devices represent physical storage. Some block devices represent remote storage. Some block devices are purely virtual and can only be layered on top of other block devices (crypto, raid).

OPI is simply using this long established model and calling the objects that get stacked "volumes". To build a volume that does inline encryption of data, you'd layer a CryptoVolume on top of an NVMeVolume, for example. You assign the top-level volume_id into a subsystem when you create a namespace.

Note also that the stacks do not need to be linear. RAID would aggregate, a partition splits, etc. That's why each layer has to return their own new volume(s).

Thanks for this insight @benlwalker and thank you for your patience!
In a linux system when you see a volume it can specify the type and you can learn the stacking. However if everything is called volume object and identified as volume_id I suspect our APIs will look very confusing. I mean we are calling VolumeEncryption but the APIs and references from other objects will look very ambiguous - everything is a volume_id the stacking is implicit.

This also begs a question, where do we indicate this stacking of multiple services applied to a remote NVMe volume in them iddleend APIs?

[glimchb]

1. create remote NVMe volume -> get back volume_id as a result
2. create VolumeEncryption volume -> pass previous volume_id as an argument and get back new volume_id as a result
3. create VolumeCompression volume -> pass previous volume_id as an argument and get back new volume_id as a result
4. create subsystem/controller/namespace -> pass previous volume_id as an argument

works ?

[jainvipin]

@glimchb - the way I see the sequence:

• Create Namespace, which refers to a volume_id of VolumeEncryption
• Create VolumeEncryption, which refers to a volume_id which refers to a volume_id of VolumeCompression
• Create VolumeCompression, which refers to a volume_id, etc.

Isn't this confusing to the user as to which volume_id is referring to what object?

[benlwalker]

@jainvipin Please propose how you would do arbitrary layering, where the order of the layering matters and it isn't always 1:1 and not all layers always exist. I think if you do that, you'll quickly see that the handles all have to be the same type and interchangeable like Boris outlined.

[jainvipin]

@benlwalker - you may be right, let me think over something that may look better. If not we go with what we have.