Skip to content

Manage group & organization members via a separate resource #139

@ethanndickson

Description

@ethanndickson

Currently, coderd_group resources have their members managed via the members field, e.g:

resource "coderd_organization" "myorg" {
  name = "myorg"
  members = ["{uuid}", "{uuid}", "{uuid}", ...]
}

If a user were to be added to a group via the UI, the next terraform apply would detect configuration drift, and remove that user such that the Terraform config is the source of truth. To avoid this behaviour, we allow users to opt out of having the group members managed by Terraform, by simply providing null for the members attribute. When this is the case, the provider won't even inspect the members of the group in any way.

This isn't great UX, as it doesn't allow you to manage some users through Terraform, and still be able to add users manually.

This is also relevant to the new organization resources, which also need to associate members to them via Terraform.
Instead, it might be worthwhile to associate users to groups and orgs via a new resource, i.e.

resource "coderd_organization_member" "user_to_org" {
  id = "{uuid}"
  org = "{uuid)"
}

If the members field on both groups & organizations was then removed, this would enable the org member configuration to safely drift, and may enable more sophisticated Terraform setups (e.g. Associating members to an org in a loop).

From here, members could be assigned to groups in two ways:

resource "coderd_organization_member" "user_to_org" {
  id = "{uuid}"
  org = "{uuid)"
  groups = ["{uuid}", ...]
}

Since groups are org-wide, we could remove the groups attribute on a coderd_user, and have groups be associated when the user is associated with the org, via this new resource. However, this has the same issue mentioned above, where adding a user to a group via the UI will prompt Terraform to detect config drift and remove them from it on the next apply.

resource "coderd_group_member" "user_to_group" {
  id = "{uuid}"
  group = "{uuid}"
}

Alternatively, to address the aforementioned config drift, we could have another resource specifically for assigning users to groups.

We also need to make a similar decision for how roles should be assigned to a user.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions