## Background Zero Console is the idea to make .com/SM more like Dedicated and that we don't allow folks to configure their system via the Rails console so we can limit the customizations that put migrations to Dedicated, upgrades, support more challenging than it could be if we better enabled management of the GitLab instance to follow best practices. As discussed in the [platforms leads sync](https://docs.google.com/document/d/1MswZ8J1m0arCs4Ojmyz4wVDDsFtT-vtuyxXxLAoI5lM/edit?tab=t.0#bookmark=id.a6u8dvr9p5tz) the goal would be to turn uses of the rails console into in-application features/functionality. In Dedicated, they've adopted: 1. Read-only access for investigation is acceptable 1. Write-mode needs to have been recommended by the team owning that piece of code and only accepted if the Stage Group has commitment that the fix will come into the Release. We added the policy in our Request-for-Help [template](https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/team/-/blob/main/.gitlab/issue_templates/request_for_help.md#gitlab-rails-console-last-resort----optional). Rails console access would remain for break-glass situations/incidents. ## References 1. [Notes - Project Zero Console](https://docs.google.com/document/d/1938X_wkPyRxPfLWBjb4a1xHwuPPAqGUE1y_u9T-bggE) 1. https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/25880+ 1. https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/9140+ ## Goal Reduce reliance on Rails console access by moving functionality into in-application features while maintaining necessary break-glass access for incidents. ## Short-term Phase (0-3 months) - Critical Infrastructure Updates - Complete Rails console RW requests migration to Teleport (https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/23661) - Implement auto-approval system for read-only Teleport access requests (https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/25910) - Create automation in code review process to flag features lacking proper in-product controls (https://gitlab.com/gitlab-org/gitlab/-/issues/513463) - Change management plan with PMs and EMs to prevent new feature introductions that require rails. - Documentation & Policy - Document current Rails console usage patterns from Support team feedback - Establish policy for when Rails console access is acceptable - Create template for documenting console-required operations - Implement tracking system for console access requests - create a report / identify top offenders and TPM to work with EM/PM to burndown items in the report ## Medium-term Phase (3-6 months) - Support Tooling Enhancement - Audit existing runbooks at gitlab-com/support/runbooks/ and replace uses of console with in product - features or feature requests for needed functionality - Create standardized library of approved Rails commands for common support operations Develop documentation for runbook creation and maintenance - Documentation Cleanup - Review all documentation containing "go to rails console" instructions (https://docs.gitlab.com/search/?q=rails%20console) - Create tracking issues for each case requiring in-app feature development - Update documentation to prefer UI/API solutions where available ## Long-term Phase (6-12 months) - Feature Development - Work with Settings/Admin teams to create sustainable UI-based solutions - Implement specialized tooling for bulk operations (similar to Mechanizer tool but supported long-term) - Develop proxy system for executing approved commands without direct console access - Process Implementation - Establish ownership model for console-replacement features - Create change management process for transitioning from console to UI - Implement monitoring and reporting on console usage reduction ## Key Success Metrics - Reduction in Rails console access requests - Percentage of operations moved to UI-based solutions - Decrease in number of runbooks associated with console access - Time to resolution for support cases previously requiring console access ## Dependencies - Coordination with CorpSec for Teleport integration - Support team availability for testing and feedback - Product team bandwidth for defining UI-based solutions - Engineering resources for tooling and UI-based solutions development ## Epic template for sections <details><summary>Template</summary> ``` # Zero Console Initiative - [SECTION NAME] Section ## Summary As part of improving GitLab's operational efficiency and maintainability across all deployment types (.com, Self-Managed, Dedicated), we need to reduce reliance on Rails console access by providing proper in-app features or supported tooling. This epic tracks the evaluation and migration of console-dependent operations owned by the [SECTION] Section. The parent epic for this work is https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1426+. Initially tagging this as ~"type::maintenance" but this could turn into ~"type::feature" ## Background - Rails console access should not be required for routine operations or configurations - Current workflows that require console access need migration to proper product features or supported tooling - This initiative covers all GitLab deployment types and installation methods - Goal is to improve maintainability, security, and user experience across the platform ## Objectives 1. Audit existing console-dependent operations owned by this team 2. Identify proper product features or tooling needs 3. Implement necessary changes to eliminate console dependency ## Tasks ### Audit Phase - [ ] Review all operations requiring console access: - Configuration changes in gitlab.rb - Debugging workflows - Administrative operations - Data modifications - Support procedures - [ ] Document each operation in the following format: - Operation description - Current method (console command, gitlab.rb setting, etc.) - Use cases/frequency - Impact on different deployment types - Current workarounds (if any) ### Planning Phase - [ ] For each identified operation, determine: - [ ] Should it be a UI feature? - [ ] Should it be an API endpoint? - [ ] Could it be handled by other tooling (e.g. Switchboard)? - [ ] Does it need a new admin tooling solution? - [ ] Is it a one-time operation that needs proper documentation? - [ ] Estimated complexity and impact of implementation ### Implementation Phase - [ ] Create sub-issues for each required change - [ ] Coordinate with relevant teams (UI, API, Switchboard, etc.) - [ ] Ensure proper documentation and migration guides - [ ] Ensure that the setting/feature is accessible at the correct level for the deployment type (.com, Self-Managed, Dedicated) - [ ] Consider automation opportunities ## Current Operations List <!-- Add list of console-dependent operations owned by this team --> 1. [Operation Name] - Current Method: - Use Cases: - Frequency: - Impact: - Proposed Solution: ## Acceptance Criteria - [ ] All identified console-dependent operations have an implementation plan - [ ] New features/tools are implemented and documented - [ ] Migration guides are available for existing installations - [ ] Support documentation is updated - [ ] No new console-dependent operations have been introduced - [ ] Existing operations have been migrated to supported in-app features or tools ## Dependencies - UX review for new features - API design review - Documentation team support - Potential infrastructure changes ## Related Links - Parent Epic: https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1426+ - RuboCop/Danger Rule Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/513463+ /label ~"section::[SECTION]" ~"zero-console" ~"type::maintenance" ``` </details>