<!--The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution.--> ### Problem to solve Customers have to look in multiple places for information to troubleshoot replication and verification issues with Geo - such as logs, rails console, output of rake tasks and the UI. It would be beneficial if we can surface some of this information on the UI. Provide granular information about replication and verification to help with troubleshooting issues. The Geo backend holds valuable information that a customer will find useful when troubleshooting replication and verification issues such as those described here https://gitlab.com/gitlab-org/gitlab/-/issues/361612#note_946489068. The outcome we want to achieve is to increase the success rate of customers resolving replication/verification issues on their without needing to escalate to GitLab support. ### Intended users * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) ### User experience goal The systems admin should be able to easily identify a failing object and drill down to see the details related to this object. We want to make this scalable such that it does not consume a lot of resources on the user's browser and is sufficiently responsive for any replicable. ### Proposal As a first step we can expose the registry information as described here https://gitlab.com/gitlab-org/gitlab/-/issues/361612#note_946489068 for each object. ``` id bigint retry_at timestamp with time zone last_synced_at timestamp with time zone created_at timestamp with time zone state smallint retry_count smallint last_sync_failure text force_to_redownload boolean missing_on_primary boolean verification_started_at timestamp with time zone verified_at timestamp with time zone verification_retry_at timestamp with time zone verification_retry_count integer verification_state smallint checksum_mismatch boolean verification_checksum bytea verification_checksum_mismatched bytea verification_failure character varying(255) ``` We will need to review and find suitably friendly labels for each field. ### Implementation Guide - [ ] Add as many registry fields as possible to https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/graphql/types/geo/registry_type.rb - [ ] There are some inconsistencies across registry tables. Either create overrides as needed in the specific `Types::Geo::*RegistryType` classes, e.g. [`UploadRegistryType`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/graphql/types/geo/upload_registry_type.rb), or, create a follow up issue for fields that require more work to expose. - [ ] Add coverage to https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/spec/support/shared_examples/graphql/geo/geo_registry_type_shared_examples.rb - [ ] Add coverage to specific registry type specs, e.g. [`UploadRegistryType` spec](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/spec/graphql/types/geo/upload_registry_type_spec.rb) ### Further details Systems administrators sometimes struggled to figured out why a replication or verification is failing, how long it has been fail for and how to remediate it. This information above will provide detailed insights into the state of the operation. This will be the first iteration to surface additional information. We will evaluate if further information such as errors from logs will be useful in future. <!--Include use cases, benefits, goals, or any other details that will help us understand the problem better.--> ### Permissions and Security Should only be available to users with Administrator privileges. <!--What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? Consider adding checkboxes and expectations of users with certain levels of membership https://docs.gitlab.com/ee/user/permissions.html * [ ] Add expected impact to members with no access (0) * [ ] Add expected impact to Guest (10) members * [ ] Add expected impact to Reporter (20) members * [ ] Add expected impact to Developer (30) members * [ ] Add expected impact to Maintainer (40) members * [ ] Add expected impact to Owner (50) members Please consider performing a threat model for the code changes that are introduced as part of this feature. To get started, refer to our Threat Modeling handbook page https://about.gitlab.com/handbook/security/threat_modeling/#threat-modeling. Don't hesitate to reach out to the Application Security Team (`@greg`) to discuss any security concerns.--> ### Documentation We should document how to find this feature and how it can be used for troubleshooting. Consider a new page dedicated to the dashboard that will include this and other information available via the dashboard that hangs off of https://docs.gitlab.com/ee/administration/geo/ ### Availability & Testing Available to Premium and Ultimate self-managed and dedicated customers Testing should ensure up to date and accurate information is available on the UI. Cross browser-testing will be needed to ensure correct rendering and performance. <!--This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? ### Available Tier Available to self-managed and GitLab dedicated customers on the following tiers * Premium * Ultimate ### Feature Usage Metrics We could instrument page views for this route to indicate how frequently customers visit these pages. ### What does success look like, and how can we measure that? Customers are able to troubleshoot most common replication issues on their own without escalating GitLab support. <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md--> ### What is the type of buyer? Self-managed and Dedicated looking to for a DR solution or for accelerating remote users. ### Is this a cross-stage feature? No ### What is the competitive advantage or differentiation for this feature? Make Geo easier to setup and troubleshoot ## Exit Criteria * Issues in this epic completed and we're able to allow customers to see more details about replicables so they can triage errors without as much manual intervention from GitLab support. The systems admin should be able to easily identify a failing object and drill down to see the details related to this object. We want to make this scalable such that it does not consume a lot of resources on the user's browser and is sufficiently responsive for any replicable. ### Participants * @zcuddy * @c_fons ### Screenshots | | Before | After | | ------ | ------ | ------ | | Filtered list view ||  | | Replicable show view ||  | ### Links / references <!--Label reminders - you should have one of each of the following labels. Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/--> <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> <!--STATUS NOTE START--> <!--STATUS NOTE END-->