Fix status codes that are returned for Get/Delete RPC calls
for VolumeGroup/VolumeGroupSnapshot.
Signed-off-by: Nikhil-Ladha <nikhilladha1999@gmail.com>
(cherry picked from commit 18a62ec9de)
We should return NotFound status if the group doesn't exists
for ControllerGetVolumeGroup RPC call.
And, an empty/OK response for DeleteVolumeGroup if the group
doesn't exists
Signed-off-by: Nikhil-Ladha <nikhilladha1999@gmail.com>
(cherry picked from commit c7d54ab776)
This commit fixes the VolumeGroup UndoReservation
by using the correct RequestName of the VolumeGroup
instead of the volumeGroupHandle.
Signed-off-by: Praveen M <m.praveen@ibm.com>
(cherry picked from commit 51d0a08112)
Each object is responsible for maintaining a connection to the journal.
By sharing a single journal, cleanup of objects becomes more complex as
the journal is used in deferred functions and only the last should
destroy the journal connection resources.
Signed-off-by: Niels de Vos <ndevos@ibm.com>
This commit adds `GetCephFSRadosNamespace` util method that returns
the `RadosNamespace` specified in ceph-csi-config ConfigMap under
cephFS.radosNamespace.
If not specified, the method returns the default RadosNamespace
i.e, csi.
Signed-off-by: Praveen M <m.praveen@ibm.com>
There is no need for the `Manager.DeleteVolumeGroup()` function as
`VolumeGroup.Delete()` should cover everything too.
By moving the `.Delete()` functionality of removing the group from the
journal to the shared `commonVolumeGroup` type, a volume group snaphot
can use it as well.
Signed-off-by: Niels de Vos <ndevos@ibm.com>
Many functions that are implemented for the volumeGroup type can be
shared with the (coming) volumeGroupSnapshot type. Move these functions
into a commonVolumeGroup type, so that volumeGroup and
volumeGroupSnapshot can inherit them.
Signed-off-by: Niels de Vos <ndevos@ibm.com>