Support Disabling Geo Replication by Resource in UI
<!-- The first three sections: "Problem to solve", "Intended users" and "Proposal", are strongly recommended, 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 As @fzimmer stated in https://gitlab.com/gitlab-org/gitlab/-/issues/213885#note_327896598: > This is a more general point where in the SSF it may be desirable to default to on but to be able to disable replication on a case-by-case reason. If you don't need packages replicated for geo-replication, we should allow users to disable it. As we continue to support more resources with the self-service framework, unnecessary replication will become more of a problem for users who only care about replication for particular resources. ### Intended users * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> ### Proposal As a starting point, here's a high-level proposal from https://gitlab.com/gitlab-org/gitlab/-/issues/280581#note_451865291 along with a couple of additional steps. 1. Add database settings for feature flagged replicables with a migration that defaults the setting to whatever the feature flag is set to. We could consider using the `geo_nodes` table for these settings. 1. Refactor to use the settings instead of feature flag. 1. Expose these settings in the UI 1. Work through the implications of adding settings for other replicables (https://gitlab.com/gitlab-org/gitlab/-/issues/215475#note_329967465) before adding to settings and exposing via UI 1. Add any documentation and code needed to support developers adding new resources via the self-service framework 1. Until secondary mimicry is implemented, ensure there is a warning that secondary functionality may break due to missing files ### Permissions and Security <!-- 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)?--> ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> ### Availability & Testing <!-- 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? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What does success look like, and how can we measure that? Users have an easy way to disable and enable replication for specific resources. Engineers are easily able to add this functionality for new resources using the self-service framework. ### What is the type of buyer? Premium and Ultimate ### Is this a cross-stage feature? ### Links / references
epic