Support and document -replace (since terraform taint subcommand is deprecated)

[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 #217 (comment)

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).

[philchristensen]

Not sure if there's been any progress on this yet, but I'd like to add my two cents.

Every time I've needed to taint recently, it would have been sufficient to just have an atlantis taint -p project command that could be run against a particular project.

For my needs, that would add enough of a record of the taint to the PR comment thread.

[jghal]

Looks like Terraform 0.15.2 introduces the -replace=<address> argument to plan, as a recommended alternative to taint in that it doesn't impact the state until the apply.

[philchristensen]

We’re an update away from TF15 but that would do the trick for me.

[piotr-vimn]

terraform taint are deprecated.
For Terraform v0.15.2 and later, we recommend using the -replace option with terraform apply instead (details below).

https://www.terraform.io/cli/commands/taint

[grimm26]

@piotr-vimn Fine, then we need the ability to use the -replace option in atlantis. Either way.

[georgekaz]

@grimm26 You can do this by passing the option as a comment arg i.e. `atlantis plan -- -replace="the_resource.the_name"

[grimm26]

@georgekaz I did not realize this because I run a custom workflow. I'm trying to incorporate COMMENT_ARGS now but it is painful.

[georgekaz]

@grimm26 I'm annoyed with myself because I probably posted the answer you need in my previous comment and then removed it because I didn't want to assume. This or similar works:

workflows:
  data:
    plan:
      steps:
      - env:
          name: TF_CLI_ARGS_plan
          command: echo $COMMENT_ARGS | tr ',' ' ' | sed -r 's/\\(.)/\1/g'
      - init
      - run: >-
          terraform$ATLANTIS_TERRAFORM_VERSION plan -input=false -refresh -no-color -out $PLANFILE | .......

[grimm26]

@georgekaz I got way more involved than that in order to support indexed resources like foo.bar["baz"] and foo.bar[0]. I ended up using a script with this in it to populate TF_CLI_ARGS_plan:

echo ${COMMENT_ARGS} | tr -d '\' | sed -r -e 's/,/ /g' -e 's/\[(.*[_[:alpha:]]).*\]/[\\"\1\\"]/g' -e 's/\[/\\[/g' -e 's/\]/\\]/g'

The extra escaping and whatever in the yaml and the command sending it to sh -c made it too hard to remove the backslashes but then put them back for brackets and double quotes in the brackets so that's why I put it in a script.

[SamuelMolling]

@georgekaz I tried using the atlantis plan -- -replace="random_password.default" command, but it keeps saying: No changes. Your infrastructure matches the configuration.

I want to recreate the user's password

[nitrocode]

@SamuelMolling try passing in a -d with atlantis plan.

atlantis plan -d some-directory -- -replace="random_password.default"

[nitrocode]

You folks are right, the taint command is deprecated in favor of -replace. I'll retitle this.

And the untaint command is not deprecated and doesn't have an atlantis GH issue for this support so I'll write one up #4464

[SamuelMolling]

Hey @nitrocode, i try too. Same problem.

atlantis plan -d users/teste -- -replace="random_password.default"

[SamuelMolling]

I tried to do the same command on another resource, but the same problem. It appears that there are no changes.

[SamuelMolling]

Do you need some specific server config, some specific allow command?