#Manage Groups with Terraform

7 messages · Page 1 of 1 (latest)

echo phoenix
#

We are looking at managing groups in terraform, but are hitting an issue with how nested groups would work, it seems like its impossible to do it without hitting cyclical issues with the code. has anyone managed to use terraform for groups without writing repetitive code. ive had a look around and can see any good examples of how people are using terraform to manage gitlab, which leads me to think thats for a reason.

lapis coral
#

We manage a full nested group structure inside TF without having cyclical issues - what type of group structure are you trying to create that you have cycle issues?

echo phoenix
#

to be honest i think the main issue im seeing the cyclical issues is that were trying to abstract away as much terraform as we can. our plan was to have a file that describes our folder structure and TF iterates over it. but terrafrom doesnt know it needs to create the parent first and get suck in a loop

  {
    "group-name": "group1",
    "description": "This is group1",
    "wiki_access_level": "enabled",
    "prevent_forking_outside_group ": true,
    "project_creation_level": "noone",
    "request_access_enabled": false,
    "subgroup_creation_level": "owner",
    "sub-groups": [
      {
        "group-name": "subgroup1",
        "description": "This is group1/subgroup1",
        "wiki_access_level": "enabled",
        "prevent_forking_outside_group ": true,
        "project_creation_level": "noone",
        "request_access_enabled": false,
        "subgroup_creation_level": "owner",
        "sub-groups": []
      }
    ]
  },
  {
    "group-name": "group3",
    "description": "This is group3",
    "wiki_access_level": "enabled",
    "prevent_forking_outside_group ": true,
    "project_creation_level": "noone",
    "request_access_enabled": false,
    "subgroup_creation_level": "owner",
    "sub-groups": [
      {
        "group-name": "subgroup1",
        "description": "This is group3/subgroup1",
        "wiki_access_level": "enabled",
        "prevent_forking_outside_group ": true,
        "project_creation_level": "noone",
        "request_access_enabled": false,
        "subgroup_creation_level": "owner",
        "sub-groups": [{
          "group-name": "subsubgroup1",
          "description": "This is group3/subgroup1/subsubgroup1",
          "wiki_access_level": "enabled",
          "prevent_forking_outside_group ": true,
          "project_creation_level": "noone",
          "request_access_enabled": false,
          "subgroup_creation_level": "owner"
        }]
      }
    ]
  }
]
lapis coral
#

Yeah, your TF will need to have some concept of how you want your groups structured, and how your want your instance group setup to look like. Otherwise it doesn't know how to iterate over the JSON

#

For example, we do:
Top level group

- Department Group
-- Department Permissions Groups 1-N (for example, "Security Engineer", "Software Engineer", "Architect")
-- Department Project Groups
--- Repositories

Then because TF knows what "Permissions Groups" are, it can enforce permissions on the Project Groups appropriately

#

You could potentially use TF CDK to achieve what you're trying to achieve by having the CDK generate the TF configuration, but I've never done that before.

echo phoenix
#

yeah im finding it a thin line between getting something that works how we want and something that our team can manage/maintain. I think i should be able to get it to work if we limit our nesting liek in your example. its probably not needed anyway 🙂