You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
Currently,
coderd_group
resources have their members managed via themembers
field, e.g: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 providingnull
for themembers
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.
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:
Since groups are org-wide, we could remove the
groups
attribute on acoderd_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.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.
The text was updated successfully, but these errors were encountered: