Switch from remote_development_agent_configs table to workspaces_agent_configs

MR: Migrate remote_development_agent_configs table (!163846 - merged)

Description

Switch from remote_development_agent_configs table to workspaces_agent_configs.

We need to rename this table to reflect the rename of the category from Remote Development to Workspaces.

See Technical Requirements section below for details.

Follow-up Issues and MRs

Task	Issue	MR
Delete table (next release, %17.5)	Delete remote_development_agent_configs table (#480767 - closed)	Delete remote_development_agent_configs table (!164032 - merged)
Delete remaining API (6 releases, %17.10)	Remove deprecated API references to remote_deve... (#480769 - closed)	Remove deprecated remote_development_agent_conf... (!183427 - merged)

• See also Rename namespace agent mapping mutations (#477965) for the rename of the related Rename remote_development_namespace_cluster_agent_mappings table to workspaces_namespace_cluster_agent_mappings - but that is a lower priority than this one, and can follow the normal/standard multi-release rename process.

Acceptance Criteria

• New table DDL is created exactly the same as old table, except for trigger to fill project_id (this will be moved to application logic)
• DML migration is written to copy all rows from old table to new table
• New logic is added to populate project_id upon record creation (eliminates need for trigger)
• All logic is updated to use new table
• All doc and text references are updated to new table
  • workspaces docs repo: gitlab-org/workspaces/gitlab-workspaces-docs@833ad06d
  • handbook: No references
• Prior GraphQL API fields and arguments for old model name are still available, but deprecated
• Thorough manual testing: See Validation steps on MR
• Follow-up issue created for deletion of old table in next release: Delete old remote_development_agent_configs table (#480137 - closed)
• Follow-up issue created for deletion of remaining deprecated API and code after 6 releases: Remove deprecated API references to remote_deve... (#480769 - closed)
• Find and update references to metric name change (follow-up issue)

Technical Requirements

Overview

This rename is high priority because Category:Workspaces has much current and upcoming work involving this table, and we want to get the rename out of the way first.

Therefore, we are not using the normal two-release rename process (involving a view), but instead are using an alternate process which can be done in a single release (by copying all data to new table, leaving the old table in place, and pointing all code to the new table).

We also know based on metrics and service ping and direct conversations with enterprise users that this table has a very low volume of records (likely 1 or zero in most cases), so there's no concerns with doing the work in regular migrations.

This approach has already been pre-approved by @jon_jenkins in the database group, and @ahegyi as a database maintainer (who will also be the database maintainer on the MR).

General Plan

This is an alternate approach to a table rename than that described in https://docs.gitlab.com/ee/development/database/rename_database_tables.html. This is because we want to avoid the need to wait for the next release, but still ensure we accommodate zero-downtime deploys and schema cache concerns. Normally this might be difficult, but it should be possible and safe in our case because of some unique characteristics of this table.

Here is the general plan, for a single MR:

1. Make a first migration for the DDL to create the workspaces_agent_configs table.
   • It should have an identical schema to the existing remote_development_agent_configs table, except that all the fields will be nullable (to save us the work of doing that separately in All remote_development_agent_configs table fiel... (#479699)).
2. Make a second migration for the DML to copy all records from the existing remote_development_agent_configs to the new workspaces_agent_configs table.
3. Make the changes to rename the RemoteDevelopmentAgentConfig model and all associated code to WorkspacesAgentConfig, so it points to the new table.

Considerations for zero-downtime deploys

Regarding multi-version / zero-downtime deployments: The old version and the new version of the application will run at the same time in a zero-downtime deployment scenario. Normally, this is a concern and requires triggers for bidirectional syncing. However, that should not be required in this case:

1. The update frequency of these tables is so infrequent, that I think it’s acceptable that we expect no new records will be written during the period of the zero-downtime deploy
2. The nature of this table is that it’s essentially just a mirror of the Gitlab Agent for Kubernetes agent config YAML which lives in git, and we are hooking into that and denormalizing it into this table. So even if we did happen to miss an update, all changes will get picked up and written to the new table on the next update of the config file. And this process is already error prone (i.e. it will fail if any of the YAML updates are valid - that’s why we’re migrating to this table instead of the YAML file for config). Worst case, we just tell users to make any dummy edit/commit to the config file, and it will ensure that all changes are reflected in the table.

Justification

After looking at the issues getting refined for Versioning Workspaces Agent Config (&14872 - closed) and elsewhere, we decided that we should not defer this rename.

Because we are going to continue to be adding many references in the code and also database foreign keys to the remote_development_agent_config table, which is just more code cleanup to do in the future.

It also means unnecessary migrations and/or extra code to work around the incorrect name, which we wouldn't have to do otherwise, and also causing confusing discussions. See #479688 (comment 2059496100) and #479461 (comment 2059401288) for examples.

Thus, this is not a piece of technical debt that we should let drag out, because it will continue compounding.

Design Requirements

N/A - no UI changes