Ability to manage strict group/project members list

[radkomateusz]

Hi, I want to submit feature request.

I want to manage whole list of group/project members by single resource as I would like to ensure that terraform configure only given set of members.

Expected behaviour: Resource ensures that only given set of members are configured. If additional members will be added manually, then TF plan/apply will remove them. If members are removed manually, then TF plan/apply will add them again.

Proposed Terraform Configuration Files

resource "gitlab_project_membership_binding" "test" {
  project_id   = "12345"
  user_ids      = [1337, 1338,1372]
  access_level = "maintainer"
}

I want to have similar concept here like in GCP provider (https://www.terraform.io/docs/providers/google/r/google_project_iam.html) - to be able manage: whole policy mapping, only binding for given access level, and also single membership (which is currently the only possible).

[thuck]

I was just thinking on something similar; but using a slight different format for the code:

resource "gitlab_project_membership_binding" "test" {
  project_id       = "12345"
  member {
     user_id       = 1337
     access_level  = "maintainer"
  }
  member {
     user_id       = 1338
     access_level  = "developer"
  }
}

So when using this we could do something on the lines:

resource "gitlab_project_membership_binding" "test" {
  for_each          = local.projects
  project_id        = each.value.name
  dynamic member {
    for_each        = each.value.members
    content {
      user_id       = member.value.user_id
      access_level  = member.value.access_level
    }
  }
}

[armsnyder]

@radkomateusz Thanks for the suggestion. However, we like to follow the HashiCorp design principle that a resource should map directly to a resource in the upstream API. Since there isn't a GitLab API for adding multiple members, I don't think we'll have a resource for it in the provider.

Take a look at count or for_each for ways to create multiple resources dynamically based on a list of ids, as @thuck shared. 😄

[radkomateusz]

@armsnyder Thanks for the answer! :)

Although I understand mentioned principle, I still have an issue which couldn't be addressed by current resources.

I'm aware of count/for_each and it resolves problem with managing multiple members, but it doesn't address issue that I want to have defined strict list of members. By count/for_each I could define eg. 10 members, but still someone with enough permission could add 11th member manually, not by terraform. After that, running terraform plan doesn't see any issue, so I couldn't rely on terraform code as the source of truth.

I want to be able to create terraform code, which will be source of truth about members/settings, which is impossible (or I don't see sth :) ) with current resources.

[armsnyder]

@radkomateusz Thanks for clarifying. The use case makes sense.

[torinthiel]

This might be hard to get with terraform, as it kind of works against it's principles. However I'd also like to have this feature.

In the meantime, if you're willing to make a few compromises, it should be possible to get a list of 'offending' users by creatively combining the gitlab_group_membership datasource with some clever mappings of your TF-described user list and using the setsubtract function.

Later you have several options, depending on the compromises you're willing to make, e.g.

• Use ansible and https://docs.ansible.com/ansible/latest/collections/community/general/gitlab_group_members_module.html to remove the offenders (triggered by some use of null resource and provisioner)
• set it as output and use terraform output offenders to act upon this later in the pipeline
• fail the build immediately with e.g. https://registry.terraform.io/providers/bwoznicki/assert/latest/docs/data-sources/test

[headyj]

Any news on that? because the data source does not fulfill this request. @radkomateusz I don't think this is a problem, as many providers are doing the same thing. For example AWS provider is providing both aws_security_group resource (on which you can provider ingress an egress rules) and a specific aws_security_group_rule resource as well

[radkomateusz]

Hi @headyj, I'm not sure if you mean me in above comment ;) I don't see any problem with that also, as mentioned AWS/GCP providers are doing the same thing (breaking this convention).

I still think that resource (not a data source), for managing all members of project/group will be useful.

@torinthiel, thanks for the ideas.

[headyj]

Yep sorry @radkomateusz, I just wanted to mention @armsnyder obviously ;)

@armsnyder is someone working on this feature? it was opened a year ago now. If not I can do a PR for that one

[armsnyder]

@headyj I don't think anyone is working on this. Contributions are welcome!