Skip to content

Workspaces can be created under user or project namespaces

MR: Pending

Description

As a workspaces user, I want to be able to start a workspace under my personal user namespace so that I am not required to create it under a group.

This should likely be expanded to include ProjectNamespace as well, as the changes to policies should be very similar and we already will have the actual policy logic abstracted and reusable.

Related discussions and issues:

Acceptance Criteria

  • Users can create workspaces under their user namespace
  • Cleanup up all unnecessary creation of group fixtures in the specs. E.g. just use agent.project.project_namespace instead of unnecessarily creating the agent's project with a group. We can still have some isolated integration-level tests (e.g. one of the main_integration_spec.rb) to test all possible namespace sub types: Group, UserNamespace, ProjectNamespace

Technical Requirements

See this thread on Add mutation APIs for group-agent authorizatio... (!145387 - merged) for a patch with a preliminary implementation of this.

NOTE: The following collapsed section contains the previous Technical Requirements section, but this is likely outdated and irrelevant due to the implementation of Add mutation APIs for group-agent authorizatio... (!145387 - merged) and FE: Use group-agent mapping API in Create Works... (#444860 - closed)

Previous Technical Requirements (outdated) See this internal slack thread for a discussion and investigation of this.

Here are some notes from that thread around the investigation:

Looking at the code for this, haven’t had time to debug it yet, but leaving notes here for when I (or someone else) can:

  • We use the ee/app/assets/javascripts/remote_development/graphql/queries/get_group_cluster_agents.query.graphql query
  • Which is in the scope of the “group” (in this case a user namespace)
  • Which uses the pre-existing cluster agents resolver app/graphql/resolvers/clusters/agents_resolver.rb
  • Which uses the pre-existing finder app/finders/clusters/agents_finder.rb
  • Which looks up in the context of the “group” using #cluster_agents in ee/app/models/ee/group.rb
  • Which uses all_projects, which has this definition:
  def all_projects
    namespace = user_namespace? ? self : self_and_descendant_ids
    Project.where(namespace: namespace)
  end

You can see here if the “group” is a user_namespace, then it’s defined as ONLY the projects for the current namespace.

So, presumably this SHOULD pick up the agent if it’s on a project somewhere in the same user_namespace.

But it doesn’t seem to be.

Interestingly though, it does seem to pick it up if it’s in the same project:

As an aside, I CAN create a workspace where the devfile and cluster agent reside in the same repo. This knocks out one of the possibilities we were looking at earlier in the conversation.

Would have to debug this scenario to see exactly what’s going on.

Looking at the code for this, haven’t had time to debug it yet, but leaving notes here for when I (or someone else) can:

  • We use the ee/app/assets/javascripts/remote_development/graphql/queries/get_group_cluster_agents.query.graphql query
  • Which is in the scope of the “group” (in this case a user namespace)
  • Which uses the pre-existing cluster agents resolver app/graphql/resolvers/clusters/agents_resolver.rb
  • Which uses the pre-existing finder app/finders/clusters/agents_finder.rb
  • Which looks up in the context of the “group” using #cluster_agents in ee/app/models/ee/group.rb
  • Which uses all_projects, which has this definition:
  def all_projects
    namespace = user_namespace? ? self : self_and_descendant_ids
    Project.where(namespace: namespace)
  end

You can see here if the “group” is a user_namespace, then it’s defined as ONLY the projects for the current namespace.

So, presumably this SHOULD pick up the agent if it’s on a project somewhere in the same user_namespace.

But it doesn’t seem to be.

Interestingly though, it does seem to pick it up if it’s in the same project:

As an aside, I CAN create a workspace where the devfile and cluster agent reside in the same repo. This knocks out one of the possibilities we were looking at earlier in the conversation.

Would have to debug this scenario to see exactly what’s going on.

Implementation Guide

See Technical Requirements section above, which contains a link to a comment with a preliminary patch implementation.

NOTE: The following collapsed section contains the previous Implementation Guide section, but this is likely outdated and irrelevant due to the implementation of Add mutation APIs for group-agent authorizatio... (!145387 - merged) and FE: Use group-agent mapping API in Create Works... (#444860 - closed)

Previous Implementation Guide (outdated) If this gets picked up as Seeking community contributions, please see the "Technical Requirements" section above.

The main thing needed to move this issue forward is to explore the behavior of the all_projects method, and explain why it does not pick up projects under a user namespace.

This initial investigation should not require you to set up or necessarily know anything about Workspaces or the Remote Development feature.

Design Requirements

No UI changes needed, this is only changing the underlying declarative policy authorization rules.

Impact Assessment

This will allow wider adoption and usage of the Workspaces feature, by not requiring usage of or access to group-level authorization when mapping agents and creating workspaces for those agents.

Edited by Chad Woolley