csi-addons / spec Goto Github PK

As part of csi-addons/kubernetes-csi-addons#116,
We volumereplication as capability that can be advertised by csi-drivers.

https://github.com/csi-addons/spec/tree/main/identity#getcapabilities

/assign @yati1998

for all RPCs:
in addition to the existing volume_id, which represents the source volume, add a target_volume_id parameter, which represents an existing (but new) target volume.

Ceph-CSI supports encryped storage (currently only for RBD images with LUKS/cryptsetup). There should be a way to rotate the encryption passphrases by adding a new one to the LUKS header and removing the older one.

This might be very Ceph-CSI specific, at the moment. But an advanced procedure like this does not fit in the CSI Spec, so maybe kube-storage is a better location?

Add state file to the ResyncVolumeResponse to provide more clarity about the current state of the volume

message ResyncVolumeResponse{
  // Indicates that the volume is ready to use.
  // The default value is false.
  // This field is REQUIRED.
  bool ready = 1;
  // Represents the current state of the volume which is helpful to provide the state of the volume to the user. 
  // with this user can identify that the image is still resyncing, completed, stated to resync, or failed to resync.
  string state =2;
}

Sometimes the volume might not be in a good state and the user needs to know what is the health of the replication is in an error state, need manual work like resync, etc.

This will help some automation where you will demote the volume (make it secondary) check the volume state and if any resync (if supported) is required resync the volume.

Kubernetes and the CSI Spec does not have Volume Groups support yet. Once that feature is available, csi-addons project probably want to extend the volume replication to support it too.

This issue is opened for tracking

With ceph/ceph-csi#2108 we are adding a VolumeHealer in ceph-csi. The VolumeHealer currently aims to restore the rbd-nbd processes back to life after a node plugin restart. For now, the VolumeHealer is triggered as part of the NodePlugin bootup sequence (triggers on every restart)

We hope the healing will be moved to a csi-addons sidecar in the future.

It would be a nice addition if a volume can be sparsified by running fstrim, blkdiscard or tools like rbd sparsify.

Owners of a PVC should be able to run these commands at a time of their choosing, e.g. out of business hours. Normal users on a cluster do not have the permission to run privileged Pods that are required for this, so this needs to be initiated through a controller that is managed by the (storage) admin.

I imagine an interface similar to Job from the batch/v1 API, with some potential to add scheduled jobs like CronJob.

Currently, we don't have any check-in CI to make sure the user-generated the profiles after changing some text in the proto spec in Readme.

example PR this happened is #33. good to check this in CI.

Similar to the CSI Controllers, I imagine it would benefit consumers to have a detection mechanism of what Controllers are available, and what functionalities it provides.

An Identity Service kind of API could provide access to details like:

• ReplicationController
  • API version, other information about provider
  • capabilities: ENABLE_DISABLE, PROMOTE_DEMOTE, RESYNC
• FencingController
  • API version, other information about provider
  • capabilities: BLOCK_NODE, UNBLOCK_NODE, NODE_RECOVERY
• DataEncryptionController
  • API version, other information about provider
  • capabilities: KEY_ROTATION, SHRED

Adding the Identify Service from the beginning shows the intent to do more than replication alone. The README mentions fencing in a diagram, but it is omitted everywhere else.

Configure mergify to auto-merge the PR when CI is passing and PR is having the required approvals.

details about mergify at https://github.com/Mergifyio/mergify-engine

It would be amazing if CSI-Addons can provide a way to temporary quiesce I/O while a volume snapshot is made.

The process could look a little like this:

1. a user initiates Quiesce
2. csi-addons execs a command in the application container (flush I/O, pause VM, ...)
3. csi-addons calls fsfreeze or similar the NodePlugin where the volume is mounted
4. the user creates a snapshot/clone
5. csi-addons calls unfreeze or similar the NodePlugin where the volume is mounted
6. csi-addons execs a command in the application container (resume VM, ...)

add update_time/last_sync_time to the ResyncVolumeResponse to update the actual resync that happened to time in the backend and this field is optional.

// ResyncVolumeResponse holds the information to send when
// volume is successfully resynced.
message ResyncVolumeResponse{
  // Indicates that the volume is ready to use.
  // The default value is false.
  // This field is REQUIRED.
  bool ready = 1;
   // Timestamp of last resync update on the volume
  // This field is optional.
  .google.protobuf.Timestamp updated_time = 4;
}

open for suggestion on the field name updated_time or last_resync_update anything else?

CC @ShyamsundarR @raghavendra-talur @oriyarde