BE: Create migration script that is co-deployed with the feature flag enabled
MR: !154326 (merged)
Description
The background for this lies in the question: how do we deal with users that are currently using workspaces with using the (soon-to-be) legacy agent authorization strategy?
After exploring some ideas with the team, a solution proposed by @vtak is to create a migration script that will migrate the existing agents (with RD capabilities) to the root namespaces where they reside. The "Gitlab Migration Bot
" user will be used as the associated user to create these mappings.
The outcome of the migration will be that users will continue to see at least the same agents that would've been visible prior to the migration.
Rollout Strategy
The complete rollout strategy for the feature will be as follows:
- (Starting state): Feature flag is disabled and data store is in production
- Deploy all BE/FE MRs
- Enable feature flag for select customers to verify if the feature works as expected
- Feedback/dev loop to accommodate any changes/fixes before the feature can be considered ready
- Now that the feature is ready, merge MR with the migration script and with the feature flag enabled. These must be deployed in the same MR. This also implies that the feature will be enabled in one go for everyone.
- If the migration runs first and the feature flag is enabled in some later MR, then there is a potential risk of not migrating any candidate agents introduced in the interim.
- If the feature flag is enabled first and the migration is run in some future deployment, then there is a risk of re-mappings agents that could have been unmapped in the interim, overriding the user's intent.
- After a waiting period of relative stability, the feature flag can be deprecated.
Edge cases to consider
User will see more agents that they could before:
Say a group project hierarchy exists rootgroup-1/group-2/agent-project-1
with a user having developer access to agent-project-1
but not developer access to group-2
. The legacy authorization strategy would not have exposed agents for agent-project-1
to the user. However, since the new authorization strategy does not check permissions at the group-level, agents tied to agent-project-1
will be visible to the user post-migration.
This is not necessarily a permissions issue as the user will only see the agent if the required Developer+ role is present.
However, in the very unlikely configuration where an organization has deliberately restricted group-level Developer access but somehow granted Developer role to the agent-project-1
, knowing and expecting that the user should not see such agents (which would be very strange way to gatekeep access), the migration script would break this contract by exposing the newly-mapped agent to the user (because the new strategy does not expect group-level access checks but only verifies access at the agent project level).
Should migration be skipped for early adopters
This affects all customers for whom the migration script is enabled at step 3. Between this stage and complete rollout, we can expect updates from the customers which in theory should not be overridden when the migration is across the board in step 5.
However, there are challenges to this:
- The migration script could, in theory, have a skiplist to skip migration for some orgs/root groups. But should we do this? This makes the migration logic more convoluted and the script less generalizable (how do we run the script with skiplist for GitLab.com but an empty skiplist for self-hosted installations?
Another alternative would be to coordinate with the early adopters and highlight this risk/assist them with any guidance/preparation prior to Step 5. being carried out which sounds like a better option that doesn't involve overcomplicating the migration script.
Migration risk if feature is ever disabled after rollout
Consider the following sequence of events:
- Migration runs and feature is enabled for everyone
- Mappings are created / removed for a period of time
- Due to extreme circumstances, feature has to be disabled
- When the feature is ready to be enabled again, the migration script should NOT be run again. Running the migration will have the effect of overriding an updates that had been carried out between steps 1 and 3, which will be surprise.
Acceptance Criteria
-
Post-migration users see at least the same agents as exposed by the legacy authorization strategy
Technical Requirements
-
Implement the migration script with any specs to verify changes -
Enable feature flag
Design Requirements
NA
Impact Assessment
Some risks and extreme edge cases have been highlighted in the feature description
User Story
NA