Move the terraform logic to membership repo?

[tim-schilling]

It would be nice to create a PR and have it close the corresponding issue for people. Or have people add themselves in a PR. Thoughts?

[cunla]

I am definitely for automating this process and have users add themselves.

Because the terraform manages more than memberships, we might want to change the repo name to management or something similar.

[tim-schilling]

I agree management would be better if we were the primary users. However, that repository is meant for the non-admins and should be something that indicates that's where they belong. Our needs and understanding are secondary to theirs.

Does that perspective change your suggestion?

[cunla]

I agree management is not a good name here. Perhaps org-settings or configuration? I am still for automating the process and have users create PR to add themselves.

[tim-schilling]

What if we just move it over and keep the name membership for now?

[cunla]

I am ok with that.

[tim-schilling]

Notes from meeting:

• Concerns about secrets
• There's a repo setting to enable changing org level things

[Mogost]

https://github.com/django-commons/controls/blob/44801c84b25cf760c6012581a4142ce0ab3fdab5/terraform/production/org.tfvars
This file can get very large.

How about instead creating a small GitHub App whose code and behavior is managed from this repo, and not storing the user's hardcoded username here?
The workflow might be like that:

1. A user creates a ticket in the repo
2. Get approved somehow (?label?)
3. Application triggered do the right job

In addition, the invitation sent may become stale and the person may want to re-generate it. This case will most likely not be processed now.

Furthermore, nicknames on GitHub are subject to change. And just because we have a username now, it doesn't mean that in the future the username will be the same person. That's why you should rely on the author of your GitHub issue, even if you change your nickname, it won't change.

In some ways what Dependabot application does is similar. it understands commands inside PR like @dependabot rebase and does what it needs to do. So there could be commands like @app approve, @app regenerate invitation, @app kick me from org.

https://probot.github.io/docs/ might be a good tool to do this automation. Also might be deployed to AWS lambda near to free cost.

[tim-schilling]

Thank you for the feedback. I think we're likely to stick with our current approach for a while or at least until we experience pain.

In addition, the invitation sent may become stale and the person may want to re-generate it. This case will most likely not be processed now.

This is solved by generating a new PR. 🤷 not great, but it's there.

Furthermore, nicknames on GitHub are subject to change

This is a good point. I wonder if our terraform hash file could contain the underlying id of the user so that we don't grant a different person permissions.

[cunla]

Furthermore, nicknames on GitHub are subject to change

This is a good point. I wonder if our terraform hash file could contain the underlying id of the user so that we don't grant a different person permissions.

Interesting question. I am not 100% sure, but based on my understanding - when a username changes, the attributes should be updated in the terraform current state file, however, the index_key should remain unchanged.

 {
        "index_key": "cunla",
        "schema_version": 0,
        "attributes": {
          "downgrade_on_destroy": null,
          "etag": "W/\"a3c10fc75649b3e5e48c8279e7e7c51d1ea69eda1ece022200317e226a312071\"",
          "id": "django-commons:cunla",
          "role": "admin",
          "username": "cunla"
        },
        "sensitive_attributes": [],
        "private": "eyJzY2hlbWFfdmVyc2lvbiI6IjAifQ=="
      }

We can run an experiment for this to see the behavior