Improve volume import API response

[scaleoutsean]

Describe the solution you'd like

It'd be nice to have API response for import volume more complete, for example:

• iscsiTargetSecret - doesn't seem relevant to the user using import volume - could be omitted or obfuscated
• backend - if it was provided it'd save us one more call to Trident API, and a cross-comparison
• blockSize - likewise, it's "expensive" to get this info
• (not currently available) - snapshots - list of 24 recent snapshots or snapshot IDs that exist for this volume

Describe alternatives you've considered

• backend: to get backend (name) we need to get backendUUID from this output, then get trident backends to get backend UUIDs and names, and match the backendUUID against these to find backend (name)
• blockSize: requires the establishment of a connection to storage API endpoint (which may be hard to get) and one call to get it (kubectl describe pv doesn't have that info)
• snapshots: like blockSize, it's cumbersome to get this info; it's useful in general and potentially for import snapshot in the future

Additional context

$ kubectl describe pv pvc-5d087b4a-5149-4cc3-b332-76a54b9430e7
Name:            pvc-5d087b4a-5149-4cc3-b332-76a54b9430e7
Labels:          <none>
Annotations:     pv.kubernetes.io/provisioned-by: csi.trident.netapp.io
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    basic
Status:          Bound
Claim:           default/postgresql-data
Reclaim Policy:  Retain
Access Modes:    RWO
VolumeMode:      Filesystem
Capacity:        1Gi
Node Affinity:   <none>
Message:         
Source:
    Type:              CSI (a Container Storage Interface (CSI) volume source)
    Driver:            csi.trident.netapp.io
    FSType:            ext4
    VolumeHandle:      pvc-5d087b4a-5149-4cc3-b332-76a54b9430e7
    ReadOnly:          false
    VolumeAttributes:      backendUUID=a5af6af4-10a6-4982-8289-929a5c48e5d6
                           internalName=pvc-1e396de7-bc8f-4a16-ba3b-d62293c511ac
                           name=pvc-5d087b4a-5149-4cc3-b332-76a54b9430e7
                           protocol=block
                           storage.kubernetes.io/csiProvisionerIdentity=1616948357056-8081-csi.trident.netapp.io
Events:                <none>

$ ./trident-installer/tridentctl version -n trident
+----------------+----------------+
| SERVER VERSION | CLIENT VERSION |
+----------------+----------------+
| 21.01.1        | 21.01.1        |
+----------------+----------------+

[balaramesh]

@scaleoutsean when you say API response, I am assuming you are referring to Trident's REST invocation/VolumeAttributes exposed by Trident on the PV. Is that right?

Can you also share what persona/hat you are wearing while expecting these details? The reason I ask for this is to better understand who these details are required by/how they can be provided.

For example, backendName is already visible for the person performing the import (and is part of the import call). Each volume has backendUUID VolumeAttribute and not a backendName. I assume it is because a backendName can be updated and this will cause a drift for existing volumes.

[scaleoutsean]

Yes, I meant the API response to tridentctl import volume call.

items:
- Config:
    blockSize: ""
    cloneSourceSnapshot: ""
    cloneSourceVolume: ""
    cloneSourceVolumeInternal: ""
...
  backend: ""
  backendUUID: bbbbc73a-9d3a-4b0e-b457-c5de52a5da78

Why I ask for backend (Name): mostly because the field is already there in the response and also known to Trident, so it just needs to be populated which I thought would be a good thing to do if any changes to this API response are made. Now I provide a backend (Name) and the command - if successful - returns a backendUuid which I can verify by cross-referencing against the output of get backends which isn't difficult but requires another command. As you say get volume is exactly the same response (I didn't notice that before) so it works in reverse too - if I get volume, I need to get backends after that in order to see what backend name that is. Why do I need to do these things in the first place? I can't suspend a backend or change certain backend details without reinstalling a backend, but usually I just want to verify output.

Each volume has backendUUID VolumeAttribute and not a backendName. I assume it is because a backendName can be updated and this will cause a drift for existing volumes.

Currently backend is there but always empty, so I thought the lack of data in response was merely an omission. I don't know if it was originally envisioned to be populated but later abandoned because that field doesn't contain unique information, however currently we can't get a volume into Trident only with import volume which resets importBackendUUID and name. I assume backend (Name) would be set on import the same way so backend Name drift wouldn't happen. This isn't to say we should get it in just because we can - I just thought we could populate it since the field is already there: it'd probably be the same lookup as for backendUUID, just select one more field (backend) and populate that field in the API response - that would make things slightly more convenient.

blockSize: I assume this is the volume (not filesystem) block size. If I want to create another volume like it and setup replication between the two, I'd like to have this info handy (and this one cannot drift). I can get this info via the storage API, but I need to make 3 calls vs. 1 - tridentctl get volume to get a volume's internalName, another to connect to the storage array, get volume by its internalName, and finally get volume block size info. You could say "but you still need to connect to storage to setup replication" and that's true, but like backend, it'd help us use fewer calls and the field is already there (not sure if it can be obtained from all backends or only *-san).

snapshots: for the backend reinstall and site failover use cases. When I reinstall a backend, the K8s admin loses track of all snapshots. If I could get this info on import (and, now that you mention the same info is returned in get volume) and later on as well, it'd help me figure out what snapshots are available for the volume. Currently if I have to make a change that requires a backend reinstall, all snaps become invisible to the K8s admin. If I need to fail over to another array with a copy of my volumes, I could get some very basic information about snapshots that may have been replicated with the volume. If Trident could query and return existing volume snapshot info (IDs or names), at least I'd have something to work with until import snapshot becomes available (and that feature could build upon this functionality). Without snapshot info returned in import volume response I need to get internalName, connect to the backend API, list snapshots and work with that. With several (8, 12, 24) recent snapshot IDs returned in this response, the K8s admin could easily know which one is most recent and if need be make a clone volume that could be imported (not exactly import snapshot level of convenience, but not too bad either). The difference vs. importing a volume and taking a snapshot so that "I can access my imported volume and I have at least one snapshot" is:

• maybe replicated snapshots are app-aware snapshots so I want to start from that particular point in time, and
• maybe several apps had (a group) snapshot taken at the same time, or my apps stopped at different times and I'd prefer to restart such apps from a known common time point