Protocells Code Yellow Interlock - Migrate First Cohort
## Executive Summary
[Protocells](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1616) is a **Code Yellow** (high urgency for R&D) initiative that will introduce the [Cells](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/cells/) architecture to help horizontally scale GitLab.com and bring fault isolation. Such a large architecture change will require us to update how routing works to route to the correct cell and have certain features support the Cells architecture.
### Engineering Assessment
#### Feature Parity
- **KAS Routing**: We will have a KAS service per Cell, but all will be accessible under `kas.gitlab.com`. We need to add support to [HTTP Router](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/cells/http_routing_service/) to route to the correct KAS service.
- **SSH Routing**: We need to route the SSH requests to the correct Cell to serve git data. We have a [design document](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/cells/ssh_routing_service/) how this needs to be implemented.
- **Hosted Runners per Cell**: All services should be Cell local for the fault isolation the Cells
- **OAuth**: Needed for Duo as well as avoiding other breaking changes when we move customers to their own Orgs and Cells.
### Dependencies
#### Feature Parity
Impact description:
- High: Critical to project, will delay viable of Protocells.
- Medium: There can be some workaround.
- Low: Nice to have, we can still migrate organizations.
<table>
<tr>
<th>Team</th>
<th>Dependency</th>
<th>EM</th>
<th>GTS Liaison</th>
<th>Committed?</th>
<th>Notes</th>
<th>Impact</th>
</tr>
<tr>
<td>
~"group::workflow catalog"
</td>
<td>AI Catalog</td>
<td>
@samdbeckham
</td>
<td>
@nhxnguyen
</td>
<td>
:white_check_mark:
</td>
<td>
* [AI Catalog support for Self Managed & Dedicated + Cells](https://gitlab.com/gitlab-org/gitlab/-/issues/549767)
</td>
<td>Low: We can exclude duo users from cohorts</td>
</tr>
<tr>
<td>
~"group::environments"
</td>
<td>KAS Routing</td>
<td>
@adebayo_a</td>
<td>
@daveyleach
</td>
<td>
:white_check_mark:
</td>
<td>
* https://gitlab.com/gitlab-org/gitlab/-/issues/557002+
* https://gitlab.com/gitlab-org/gitlab/-/issues/557029+
* https://gitlab.com/gitlab-org/gitlab/-/issues/557037+
</td>
<td>Low: We would have to remove users from the cohort</td>
</tr>
<tr>
<td>
~"group::source code"
</td>
<td>SSH Routing</td>
<td>
@andrevr
</td>
<td>
@daveyleach
</td>
<td>
:white_check_mark:
</td>
<td>
* https://gitlab.com/gitlab-org/charts/gitlab/-/issues/6034 needs an investigation from Delivery team. Started a thread in the issue.
* https://gitlab.com/gitlab-org/gitlab-shell/-/issues/763 we'll be looking into the topology service to confirm it provides what we need here or if we'll still blocked.
</td>
<td>High: This would mean no Git clone can work via SSH</td>
</tr>
</table>
#### Data Migration
The following dependencies are required for migrating data to a Protocell:
<table>
<tr>
<th>Team</th>
<th>Dependency</th>
<th>EM</th>
<th>GTS Liaison</th>
<th>Committed?</th>
<th>Notes</th>
<td>Impact</td>
</tr>
<tr>
<td>
~"group::provision"
~"group::project management"
~"group::compliance"
~"group::environments"
~"group::import"
~"group::runner core"
~"group::product planning" ~"group::security policies"
~"group::source code"
~"group::code review"
~"group::custom models"
~"group::authorization"
~"group::source code"
</td>
<td>Committed Sharding Key Work Needed by start of Q4 (Oct 31)</td>
<td>
@rhardarson
@donaldcook
@nrosandich
@adebayo_a
@thiagocsf
@nicolewilliams
@vshushlin
@alan
@andrevr
@francoisrose
@eduardobonet
@jayswain
@andrevr
</td>
<td>
@nhxnguyen
</td>
<td>
:white_check_mark:
</td>
<td>
These are sharding key issues listed in `Tables still to migrate` of the [Sharding Progress Tracker](https://cells-progress-tracker-gitlab-org-tenant-scale-g-f4ad96bf01d25f.gitlab.io/sharding_summary) that **already have a milestone** associated with them.
</td>
<td>High</td>
</tr>
</table>
#### Data Integrity guarantees
The following dependencies each incrementally improve data integrity guarantees (except for Row-level security; it would be huge). The more active the organization, the more likely that some unblocked data changes will be lost or become inconsistent.
| Team | Dependency | EM | GTS Liaison | Committed? | Notes |
|------|------------|----|-------------|------------|-------|
| ~"group::organizations" | https://gitlab.com/gitlab-org/gitlab/-/issues/534565+ | @mandrewsgl | | :white_check_mark: | To improve data integrity by blocking user changes since migration is not atomic |
| ~"group::organizations" | Attribute Sidekiq jobs to organizations wherever possible (https://gitlab.com/gitlab-org/gitlab/-/issues/557901) | @mandrewsgl | | :white_check_mark: | To improve migration data integrity by stopping and draining jobs |
| ~"group::organizations" | Add a Prometheus metric which tracks the number of enqueued jobs per organization (https://gitlab.com/gitlab-org/gitlab/-/issues/557902) | @mandrewsgl | | :white_check_mark: | To improve migration data integrity by draining jobs |
| ~"group::organizations" | If possible, use Postgres Row-level security to freeze an org's data (https://gitlab.com/groups/gitlab-org/-/epics/17808) | @mandrewsgl | | :white_check_mark: | To provide strong guarantees about migration data integrity |
#### Moved to future quarter
<details>
<summary>Dependencies</summary>
<table>
<tr>
<th></th>
<th></th>
<th></th>
<th></th>
<th></th>
<th></th>
<th></th>
</tr>
<tr>
<td>
~"group::Runners Platform"
</td>
<td>Hosted Runners per Cells</td>
<td>
@kkyrala
</td>
<td>
@daveyleach
</td>
<td>
:question:
</td>
<td></td>
<td>Medium: We have to only support bring your own Runner</td>
</tr>
<tr>
<td>
| ~"group::ai framework" | Duo support | @wortschi | @nhxnguyen | :question: |
https://gitlab.com/gitlab-org/gitlab/-/issues/531356+
Cells Support for Duo Agent Platform | Low: We can exclude duo users from cohorts |
</td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>
~"group::authentication"
</td>
<td>
[OAuth](https://gitlab.com/gitlab-org/gitlab/-/issues/553465) (includes sharding work needed)
</td>
<td>
@adil.farrukh
</td>
<td>
@mandrewsgl
</td>
<td>
:question: Capacity to commit depends on outcome of in-progress technical and product discussions.
</td>
<td>OAuth support is needed for Duo as well as avoiding other breaking changes when we move customers to their own Orgs and Cells.</td>
<td>High: A lot of features depend on OAuth to work</td>
</tr>
</table>
</details>
#### DRIs
- **PM**: @mjwood
<!--also add as assignee to this epic-->
- **EM**: @nhxnguyen
<!--also add as assignee to this epic-->
- **UX/PDM**: \[Name\]
<!--also add as assignee to this epic-->
- **Group(s)**: ~"group::cells infrastructure"
- **Engineering Owner**: @glopezfernandez
#### Initiative Driver - Product or Engineering?
- [ ] **Product-driven initiatives (P1/P2/P3)** - Customer-facing features or improvements driven by Product teams that require engineering resources and commitment
- These initiatives require a Product Priority label (P1/P2/P3)
- They may also receive GTM tier labels (T1/T2/T3) for external communication
- [x] **Engineering-driven initiatives (E1/E2/E3)** - Internal technical improvements that may not have customer-facing components
- These initiatives require an Engineering Priority label (E1/E2/E3)
- They have internal visibility only and are not externally communicated
- Examples include: technical debt reduction, infrastructure improvements, refactoring, dependency upgrades
#### Sizing and Funding (Optional)
- **Size**: M
- **Funding Status**: \[Funded/Partially funded/Not funded\]
---
### Hygiene Guidelines
:bulb: \_See additional details about this process at https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/
##### :one: Pre-Interlock
- [x] Update epic description with all relevant information
- [x] Ensure all dependencies are identified
- [x] Apply appropriate labels (see below)
- [x] Apply target delivery Milestone
- [x] Update interlock status as discussions progress (via label)
##### :two: Post-Interlock: once quarter begins
- Update health status weekly (via label)
- Document any newly identified risks or dependencies
- Link to implementation epics/issues as work begins
- Flag any scope or timeline changes immediately
<!--Apply appropriate labels:
- [x] Section (section::dev, section::ops, section::sec)
- [x] Stage (devops::plan, devops::create, devops::verify, etc.)
- [x] Group (group::product planning, group::project management, etc.)
- [x] Interlock Priority (Product labels = Interlock Priority::P1, Interlock Priority::P2, Interlock Priority::P3, Engineering labels = Interlock Priority::E1, Interlock Priority::E2, Interlock Priority::E3)
- [x] Investment theme (Investment theme::Core-Devops, Investment theme::Security-Compliance, Investment theme::AI across SDLC)
- [x] Platforms (platform: GitLab.com, platform: dedicated, platform: dedicated for gov, platform: self-managed)
- [ ] Subscription tier (GitLab Ultimate, GitLab Premium, GitLab Free)
- [x] Quarter (FY27 Q1, FY27 Q2, FY27 Q3, FY27 Q4)
- [x] Pre-interlock status label (interlock status::New/Proposal in progress, interlock status::cancelled, etc)
- [x] Post-interlock status label (R&D roadmap status::Executing, R&D roadmap status::Completed)
- [x] Post-interlock, once quarter begins update health weekly (health::on track, health::needs attention, health::at risk)
*For guidance on labels, see the [labels guide here](https://handbook.gitlab.com/handbook/product-development/r-and-d-interlock/#labels-guide)-->
epic