Skip to content

Display unmapped agents in Agent authorization UI

Enrique Alcántara requested to merge 444847-display-unmapped-agents-in-agent-authorization-settings into master

Issue: FE: Display unmapped agents in the group agents... (#444847 - closed)

What does this MR do and why?

NOTICE This feature is behind the remote_development_namespace_agent_authorization feature flag.

It displays cluster agents that are mapped or unmapped to group to create Remote Development Workspaces in the Workspaces group settings page. This merge request is a follow-up to !152216 (merged) and introduces the following functionality:

  1. A tab navigation to switch between two views: "Allowed agents" and "All agents".
  2. The "Allowed agents" tab displays a table with agents mapped to a group.
  3. The "All agents" tab displays a table with all the group's cluster agents. It adds a 2nd column to the table that indicates the Agent's mapping status: Allowed or blocked.

Next steps

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Description After
All agents tab with agents

all_agents_tab_with_agents.png
Allowed agents tab with agents

allowed_agents_with_agents.png
Allowed agents tab with no agents

allowed_agents_tab_no_agents.png
Either tab when there aren't agents

no_agents_in_group.png
Mobile view

mobile_view.png

With loading

error

group_with_loading_error.png

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

  1. Enable the remote_development_namespace_agent_authorization feature flag: rails c && Feature.enable(:remote_development_namespace_agent_authorization)

  2. Follow these instructions to register two cluster agents in the gitlab-org group:

    1. Create a project in the group gitlab-org named workspaces-agents-config.
    2. Create two directories in the project's repository:
      1. .gitlab/agents/remote-dev
      2. .gitlab/agents/remote-dev-two

  3. In each directory, create a file named config.yaml with the following content

    remote_development:
  enabled: true
  dns_zone: workspaces.localdev.me
  # below configuration is optional
  # they override the default values
  network_policy:
    enabled: true
    # if your GDK is configured on a public IP, you don't need to set the `egress` key in this section.
    egress:
    - allow: '0.0.0.0/0'
      except:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
    # if your GDK is configured on a different private IP, use that in the line below.
    - allow: '172.16.123.1/32'
# for debugging locally to increase log verbosity
observability:
  logging:
    level: debug
    grpc_level: warn

  4. To connect the cluster agents:

    1. In the workspaces-agent-config project, navigate to Operate -> Kubernetes Clusters.
    2. Click the button "Connect to cluster" and select the "remote-dev" agent. Connect the cluster and close the modal dialog. It doesn't matter if the cluster is not connected.
    3. Repeat step 2 for the "remote-dev-two" agent.

  5. To map one of the agents to the group, execute the following mutation in http://gdk.test:3000/-/graphql-explorer. You might need to adjust the ID number

    mutation {
  namespaceCreateRemoteDevelopmentClusterAgentMapping(input:{ namespaceId: "gid://gitlab/Group/24", clusterAgentId: "gid://gitlab/Clusters::Agent/2" }) {
    clientMutationId
  }
}

  6. Open the URL http://gdk.test:3000/groups/gitlab-org/-/settings/workspaces

  7. You should see the table populated with one allowed agent and two agents in the "All agents tab"

Edited by Enrique Alcántara

Merge request reports