Allow updating all attributes in agent configuration for remote development

Problem to solve

As outlined in #395100 (comment 131800837), the configuration of an agent to support remote development is currently immutable. There are 2 properties which we do not allow to modify

  • enabled - This means that once enabled, remote development can't be disabled without decommissioning the agent and creating a new one.
  • 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.

Proposal

dns_zone attribute

Solution 1 (Preferred)

  • 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 set force_full_reconciliation: 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.

Cons

  • No way to perform a phased "migration" of the workspace URL.

Solution 2

  • 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
  • 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 entry dns_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.

enabled attribute

Handle the edge cases to support enabling/disabling remote dev on the agent. We'll need to have logic that ensures we don't leave stranded workspaces that can't communicate with Rails.

Consider the comments made in #423506 (comment 1534505270) while tackling this issue.

Solution 1

  • Allow the following agent configuration 
    remote_development:
  enabled: BOOLEAN                # allowed values are `true`, `false`. default is `false`.
  mode: ENUM                      # allowed values are `allow_new_workspaces`, `allow_only_existing_workspaces`. default is `allow_new_workspaces`.
  • If enabled is false, agent will not initiate reconciliation with Rails. The user cannot use this agent to create a new workspace.
  • If enabled is true, agent will initiate reconciliation with Rails. Whether the user can use this agent to create a new workspace or not, depends of the value of mode.
  • If mode is allow_new_workspaces, user can create new workspaces for the agent through GraphQL APIs.
  • If mode is allow_only_existing_workspaces, user cannot create new workspaces for the agent through GraphQL APIs. The existing workspaces would continue to reconcile. The user can update the desired state of the existing workspaces.
  • It would be the responsibility of the user to ensure that all existing workspaces are terminated before toggling the enabled from true to false. If they fail to do so, the existing workspaces would be as it is and the agent will not talk to Rails until it is made true again.
Edited by Vishal Tak