In the greenfield use case, the library generates a random bucket name upon OBC creation.
Assuming the reclaim policy is set to "Retain", when the OBC is deleted, the bucket remains in the object-store (ceph for example).
In case the OBC is created again, (and assuming the Provisioner implementation safely stored the previous bucket name), a new radom bucket name will be generated by the lib.
However, even though the provisioner would be able to retrieve the previous bucket name and set it in the OB returned by the "Provision" interface, the OBC would still have the newly generated bucket name, thus leading to a discrepancy between the OBC and the OB.
A later update to the OBC would lead to an error within the lib because of the function "errIfObcConfigHasBeenModified" comparing the bucket name between the OBC and the OB.
Proposed fix is to set the bucket name coming from the OB in the OBC when doing the final OBC update at the end of the handleProvisionClaim function.
In the greenfield use case, the library generates a random bucket name upon OBC creation. Assuming the reclaim policy is set to "Retain", when the OBC is deleted, the bucket remains in the object-store (ceph for example). In case the OBC is created again, (and assuming the Provisioner implementation safely stored the previous bucket name), a new radom bucket name will be generated by the lib. However, even though the provisioner would be able to retrieve the previous bucket name and set it in the OB returned by the "Provision" interface, the OBC would still have the newly generated bucket name, thus leading to a discrepancy between the OBC and the OB. A later update to the OBC would lead to an error within the lib because of the function "errIfObcConfigHasBeenModified" comparing the bucket name between the OBC and the OB.
Proposed fix is to set the bucket name coming from the OB in the OBC when doing the final OBC update at the end of the handleProvisionClaim function.