Allow updating dns_zone in remote development agent configuration
MR: feat: Allow for DNS Zone change in RD Config (!137277 - merged)
Problem to solve
As outlined in #395100 (comment 131800837), the configuration of an agent to support remote development is currently immutable. One of the properties which we do not allow to modify is
-
dns_zone
- This means that once dns zone is set, it cannot be updated at all. If anyone makes some mistakes, they can't fix it without decommissioning the agent and creating a new one. (This issue)
Proposal
- Allow users to update the
dns_zone
in the agent configuration. - When the commit is made to the agent configuration
- For the agent, update the
dns_zone
attribute in DB. - For all non-terminated workspaces of the agent, update the
url
attribute of the workspaces in the DB and setforce_include_all_resources: true
for such workspaces. - When the agent reconciles with Rails, it will receive updated details of the workspace(the generated Kubernetes resources will have updated host for the Ingress resource). Once agent applies them, the old URL of the workspace will no longer be accessible.
- For the agent, update the
Cons
- No way to perform a phased "migration" of the workspace URL.
Other solutions considered
Make dns_zone a list
- Allow users to specify multiple
dns_zones
in the agent configuration.- Existing config is
remote_development: dns_zone: x.y.z
- New config would be
remote_development: dns_zone: - a.b.c - x.y.z
- Existing config is
- For all new workspaces, the first entry in
dns_zone
agent configuration would be used i.e.a.b.c
. - For all existing workspaces, if the DNS zone of the workspace URL is part of
dns_zone
agent configuration, it will continue as it is. - For any existing workspaces, if the DNS zone of the workspace URL is NOT part of
dns_zone
agent configuration, the workspace URL would be updated to use the first entrydns_zone
agent configuration i.e.a.b.c
. - Once user has completed the phased migration of the workspace URL, they can update the
dns_zone
to have only 1 entry.remote_development: dns_zone: - a.b.c
Cons
- Might be a little confusing to the end user. They might be under the impression that we can have workspaces with multiple different DNS zones for the same agent. Which is not the case - it would only be used for a "migration" in case someone wants to update their
dns_zone
.
Edited by Shekhar Patnaik