Closed JohnStrunk closed 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.
@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.
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.
Ok. Sounds like this is still needed.
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)
paused
field from the CRDAdditional context @cooktheryan @guymguym Since you two were the origin of
paused
andmanual
, what are your thoughts?