Open raaizik opened 1 month ago
/cc @Madhu-1
/cc @rewantsoni
@raaizik: GitHub didn't allow me to request PR reviews from the following users: Rakshith-R.
Note that only red-hat-storage members and repo collaborators can review this PR, and authors cannot review their own PRs.
/cc @Rakshith-R
@raaizik: GitHub didn't allow me to request PR reviews from the following users: Rakshith-R.
Note that only red-hat-storage members and repo collaborators can review this PR, and authors cannot review their own PRs.
"replication.storage.openshift.io/is-default-class": "true",
This should be added as a annotationand
"replication.storage.openshift.io/flatten-mode": "force",
This as a label
hope both of the above will be handled accordingly in consumer side.
Other than the above, everything else looks good to me.
@Rakshith-R I'm aware and it will.
For VolumeReplicationClass we are sending only the parameters field like we did for VolumeSnapshotClass and StorageClass, Should we send the entire spec for it or maybe the entire object that will allow us to add labels/annotations required (ramen labels, reclaimspace annotation) from the provider itself and the client would be responsible for adding missing fields like ProvisionerName and namespace for secrets and then creating/upating it.
@nb-ohad WDYT?
I will start with the later proposal first:
maybe the entire object that will allow us to add labels/annotations required
We do not want to do that, an object contains not just desired state but also status and some metadata that is local to the provider cluster. In internal discussions, we already acknowledged the need to send labels and annotations but not as part of the serialized spec we send (the data field of the ExternalResource struct). The plan is to add it to the metadata of the ExternalResource
object, similar to the kind and name. Until that is implemented we will keep on having logic in the client to add the missing metadata.
Should we send the entire spec This depends on the structure of the type, we originally used
data
because that was the desired state for configmaps and secrets. If theVolume*ReplicationClass
has a formal spec field it will make sense to serialize it instead of amap[string]string
. As a matter of fact, we are already doing something similar for theClusterResourceQuota
CR (https://github.com/red-hat-storage/ocs-operator/blob/main/services/provider/server/server.go#L376-L399)
/test ocs-operator-bundle-e2e-aws
/test ocs-operator-bundle-e2e-aws
/test ocs-operator-bundle-e2e-aws
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: nb-ohad, raaizik
The full list of commands accepted by this bot can be found here.
The pull request process is described here
/retest
/hold Holding as per https://github.com/red-hat-storage/ocs-operator/pull/2620#discussion_r1749185716 As the comment requests to add metadata (labels and annotation) and we are sending the labels and annotations both in the Data(Spec) field.
New changes are detected. LGTM label has been removed.
/hold Holding as per #2620 (comment) As the comment requests to add metadata (labels and annotation) and we are sending the labels and annotations both in the Data(Spec) field.
Can unhold now, @rewantsoni 👍
/unhold
/test ocs-operator-bundle-e2e-aws
Should we consider sending the spec of Volume*ReplicationClass instead of spec.parameter from the provider server?
I think we've had a previous discussion regarding this or similar. IMO the server should send only the info that's required and not the entire spec.
Changes
Sends two VRCs (one for image flattening) and one VGRC. Depends on #2620
RHSTOR-5753, RHSTOR-5794