backube / scribe

Asynchronous data replication for Kubernetes CSI storage
https://scribe-replication.readthedocs.io
GNU Affero General Public License v3.0
69 stars 18 forks source link

Remove `paused` from CRD #167

Closed JohnStrunk closed 3 years ago

JohnStrunk commented 3 years ago

Describe the feature you'd like to have. Now that we have a manual trigger type, I think the paused field can be removed from the CRD.

What is the value to the end user? (why is it a priority?) "Paused" seems redundant at this point, so let's simplify the API while we still can.

How will we know we have a good solution? (acceptance criteria)

Additional context @cooktheryan @guymguym Since you two were the origin of paused and manual, what are your thoughts?

cooktheryan commented 3 years ago

From an ops perspective the only reason why I would like to keep pause is that in a failover type event that needs to be the first step that I do so that when the cluster running replication source comes online it won't impact my application and persistent data.

When read we can use the manual to do a 1 time sync from Dest back to source and unpause the process.

guymguym commented 3 years ago

@JohnStrunk @cooktheryan So Ryan you mean that on failover you would set the destination to paused, so that the source could not accidentally connect and override it? Deleting the destination CR is possible too?

setting to manual will trigger a new sync (if not already running) so seems like it can't be used to do the same as pausing, also paused can be set on both side, while the trigger can only be updated on the source.

cooktheryan commented 3 years ago

exactly. In the event source would come online we need to ensure we dont get stale data or incorrect data. I would say deleting the destination CR would be bad because if you were using a load balancer or clusterIP those would both generate new addresses when the destination CR is recreated.

JohnStrunk commented 3 years ago

Ok. Sounds like this is still needed.