Specify which data a CO can safely cache

[akutz]

Currently the spec does not specify whether or not a CO can safely cache certain data, such as a NodeID. It is important to know whether or not this information should be cached or should be obtained every time it is required. For example, because the NodeID is not a single-value, its data map could be used to transport Node host-level information to a Controller host, such as a list of local devices on the node host. However, if the NodeID is cached this value should not be used for general data transport.

Cache characteristics and expectations should be explicitly detailed for each piece of data returned by the CSI RPCs.

[saad-ali]

GetNodeId was replaced with NodeGetInfo. But this is still a valid issue.
We should define that the current fields in NodeGetInfo are immutable.
Wording for it may change across reinitialization needs to be decided.

[jdef]

I'm having a bit of a hard time with this one. I thought I'd approach it by considering cases where the NodeID might reasonably change (even though COs don't want it to). For example, the plugin is uninstalled-then-reinstalled to the system. The CO isn't guaranteed to be the plugin supervisor, so it may not be aware of such a change - if the change is performed quickly, then the CO may think that the plugin has simply been restarted. Similarly, the backend storage provider may be reconfigured such that its no longer possible for the plugin to maintain the old NodeID (given that we want to support "stateless" plugins) since NodeID would be derived from the backend metadata.
Am I over-thinking this?

[saad-ali]

Options discussed with @jdef @jieyu @julian-hj:

1. Treat these values as immutable until node restart.
2. Treat these values as immutable until node plugin version is changed.
3. Once CO calls NodeGetInfo, CO will expect these values to be immutable until the SP is decommissioned by the CO.
4. CO SHOULD call NodeGetInfo at least once to initialize a node plugin, SP must assume that CO MAY not call NodeGetInfo more than once.

We agreed 4 is the least worst option, will go with that.