Geo Replicables - Share logic between FE and BE on whether Resync/Reverify is supported
What / Why
Follow up for this thread: #364727 (comment 1413247121)
Expanding from work item: #414023 (closed)
Blocked behind object storage verification: &8056 (closed)
The Geo Replicables UI has begun adding support for Resync and Reverify actions on SSF Replicables. However, these actions are not always supported depending on how Geo is configured.
We would like to disable the buttons on the UI when they are not supported and include a tooltip for the customer as to why the button is disabled.
To do this we need to create a Single Source of Truth (SSoT) between the Frontend and Backend to reference when/when not an action is supported
Conditions
@jtapiab provided a breakdown of the different conditions in this table
Resync
Data type | Local storage | Provider managed OS replication | GitLab managed OS replication |
---|---|---|---|
Git(Repository) | Yes | N/A | N/A |
File(Blob) | Yes | No | Yes |
Container registry | Yes | Yes | Yes |
Reverify
Data type | Local storage | Provider managed OS replication | GitLab managed OS replication |
---|---|---|---|
Git(Repository) | Yes | N/A | N/A |
File(Blob) | Yes | No | No (1) |
Container registry | Yes | Yes | Yes |
(1) Gitlab-managed OS replication for blobs is currently tracked by this issue.
Proposal
Create a shared method in Rails that both the Frontend and Backend can reference to determine if an action is supported for a particular data type under the current Geo configuration.
Implementation Ideas from @mkozono
- Add
def syncable? self.persisted?; end
onReplicableRegistry
. - Add
def verifiable?
onVerifiableRegistry
which delegates toVerifiableReplicator
, which callsprimary_checksum.present? && checksummable?
. - Expose these registry methods as fields on
Types::Geo::RegistryType
:syncable
andverifiable
cc/ @sranasinghe