Atlantis: Ability to run terraform taint using atlantis

[marcb1]

Terraform taint is a feature that forces certain resources to be destroyed and re-created on the next apply, https://www.terraform.io/docs/commands/taint.html
This would be really useful to have in atlantis, thought I'm not really sure how we can implement this, since we can't open empty PRs in github.

The simplest idea I have, is to have an atlantis-taint.yaml file where users can list modules to be tainted. When running atlantis plan on a PR, that file is checked and atlantis will run terraform taint for any modules in that file and commit back an empty file on the branch. Atlantis will then run terraform plan.

When user runs atlantis apply the resources are re-created and an empty PR is merged to master.

[tedwardd]

The simplest idea I have, is to have an atlantis-taint.yaml file where users can list modules to be tainted. When running atlantis plan on a PR, that file is checked and atlantis will run terraform taint for any modules in that file and commit back an empty file on the branch. Atlantis will then run terraform plan.

I like this idea but I'd like to see it implemented as a file per project where the file lives in the project root. I could see a global file getting out of hand for larger repositories such as the one I manage containing over 250 projects.

[majormoses]

@k4k as I stated in https://github.com/runatlantis/atlantis/issues/217#issuecomment-473497844

I don't think committing a file to SCM to taint resources is a good idea, what happens if someone does not then remove it before it gets merged? How would it know between the first and possibly multiple iterations (amending commits, running terraform fmt, errors, order of operations, etc) whether or not to still taint. I think it should work exactly like terraform's taint and should just be a comment driven interface and will only run a single time per comment.

[marcb1]

The idea with commiting a file is that atlantis will remove it after parsing it and tainting the resources. So the flow would be as follows:

1. User creates atlantis-terraform.taint file and adds list of modules to be tainted
2. User opens PR
3. Atlantis lock, creates a lock and prevents other users from planning another PR on the taint file.
4. User runs atlantis plan
5. Atlantis runs terraform taint && terraform plan
6. User runs atlantis plan, and atlantis re-creates resources, deletes taint file and closes the PR.

With atlantis locks we should be ok, and since atlantis will delete the file, it's never actually committed to master. I do like the single comment idea. Only downside, is if someone just wants to run atlantis taint, do they edit a random file? Since Github doesn't allow empty PR's to be opened in a repo.

[majormoses]

Only downside, is if someone just wants to run atlantis taint, do they edit a random file? Since Github doesn't allow empty PR's to be opened in a repo.

Not sure on how best to handle that. You could just add a comment to the file as to why and when you are but that also feels odd. I think it shares some commonality with #263.

[augustohp]

I am glad I've found this discussion, building on previous suggestions I was thinking something along the lines:

1. Have a [project-prefix]/.atlantis/taint-requests.sh file
2. Someone appends a terraform taint <resource> line to that file
3. Pull requests get opened, and changes are requested and made
4. Atlantis workflow is followed (atlantis plan is issued and atlantis apply follows)

I think this apprach is closely related to the one suggested by @marcb1 but fixes the issue with an empty Pull Request being made. The differences being:

• taint-request.sh file is kept, having a list of all resources that were tainted in the past is useful to spot resources which are tainted a lot (meaning they could benefit some automation strategy)
• The taint being an sh file, it could be executed. Don't know why someone would want that but an unware (of Atlantis) person would look to that file and understand quickly why it is for and what it has done to the terraform state
• Follows the GitHub convention of having a hidden directory with the name of a tool (.atlantis) inside the project

On the implementation side, Atlantis would have to look for taint-filename (default to taint-requests.sh) configuration and respect the git diff for a merageable Pull Request upon atlantis plan comments, and do nothing if no new lines are resolved from the difference.

Do you spot any problems I don't with that approach?

[jghal]

I think a custom workflow would work to pass resources to taint via the PR comment. Looking at the notes here, there is a CUSTOM_ARGS env variable that a custom shell script could parse. Then a comment like atlantis plan -- taint:<resource1> taint:<resource2> could be handled by a script that parses and handles the arguments. So a workflow like this would do the trick I think

workflows:
  standard-with-taint:
    plan:
      steps:
      - init
      - run: /usr/local/bin/taint-resources.sh
      - plan

This could also be extended to support untaint and import (#217).