When the node plugin receives a publish (== mount) call, it needs to know what device needs to be mounted. Up to now, this was done by an API request to LINSTOR. With the introduction of more aggressive caching, this often meant the request would end in a 404 since the cache did not know about the volume at all.
To fix this, we move the retrieval of the device path out of the node plugin entirely. We can simply pass the device path from the ControllerPublish() call down using the publish context. There, the cache is not an issue since for the volume to be created, some kind of modification is needed, which will always result in cache invalidation.
We also remove the request for the device path from the NodeExpand() call: we have to look at the local mount table so we get the device name from there.
With this change, the node plugin should no longer need to request LINSTOR API outside the node/storage pool information, which is not affected by this caching issue.
When the node plugin receives a publish (== mount) call, it needs to know what device needs to be mounted. Up to now, this was done by an API request to LINSTOR. With the introduction of more aggressive caching, this often meant the request would end in a 404 since the cache did not know about the volume at all.
To fix this, we move the retrieval of the device path out of the node plugin entirely. We can simply pass the device path from the ControllerPublish() call down using the publish context. There, the cache is not an issue since for the volume to be created, some kind of modification is needed, which will always result in cache invalidation.
We also remove the request for the device path from the NodeExpand() call: we have to look at the local mount table so we get the device name from there.
With this change, the node plugin should no longer need to request LINSTOR API outside the node/storage pool information, which is not affected by this caching issue.