Should filesystem be handled by CO explicitly?

[chhsia0]

Currently the filesystem handling is completely implicit to the CO. After a volume is created, the plugin will do mkfs whenever the volume is first node-staged or node-published. That means a stateless plugin would need to check if the volume already has a filesystem successfully created before or not in its node-stage or node-publish logic.

With the introduction of #222, we have a use case that the CO may want to handle the filesystem explicitly: during a volume expansion, the CO may be required to call NodeExpandVolume to signal the plugin to expand the filesystem. So here we have an inconsistency for handling filesystems between volume creation and expansion. Should this be unified by a NodeCreateVolume call for node-side work of volume creation? This would make plugin writers' lives easier, since they no longer need to check if the filesystem already exists.

The downside is that the CO need to do keep track of the state of filesystem creation and make this extra call, similar to the case of volume expansion.

[shay-berman]

I think its problematic from few reasons:

1. The csi driver is the one that responsible to create the fstype on the PV, so it make sense that the driver will be also responsible to identify the fstype exist on the PV. Not sure if CO has the capability to identify it online.
2. There is a chance that PV will be formatted even after the first time use. In this case it means that CO will not be aware on that and he could potential say that fstype exist on the PV while its not.

So I believe the plugin should be responsible to identify if fstype exist on the PV or not.

[chhsia0]

Discussed in the community sync. This would be hard for COs to decide whether the node-side volume creation call should be called for pre-existing volumes. Closing this. If there's an actual use case we can reopen this for further discussion.