Proposals, questions to Terraform

[findmyname666]

Summary

Hello all,

I was looking at implementation of terraform module recently. I have a few questions, ideas and proposals how to improve it going forward. I will use numbering order for the purpose of referencing if there will be some discussion:

1. I was thinking to add a new feature and I went through module code-base ... it was kinda hard for me to understand it and to add some new code there because of several if conditions which can change based on user's input. For that reason I would like to propose to rewrite it and use "object" representation in the code. From top of my head I would create separate classes for workspace manipulation + state and class for terraform execution. I'm willing to code some proposal in the upcoming weeks/months (based on the time) if you are OK with that. Additionally I could become the maintainer as well.

2. Features:

a) I'm used to use terragrunt/terraform combo for deployment of terraform code. Based on that I kinda missing possibility to decide if I want to apply a new changes (I'm aware of planned state). This could be achieved to first run terraform plan with colours, display it to user, ask for user input and continue based on it. This shouldn't be difficult because we run plan for apply either way in the current state. We could introduce a new argument called auto which is True by default.

b) I would benefit from the possibility to generate terraform providers based on the arguments passed to module. In real world scenario users often manage several modules. Providers needs to be specified in each module and upgrades are kinda pita. Managing providers versions from 1 place would be awesome. .tf files use hcl configuration language and I'm not sure how difficult this would be but it is worth to explore.

c) We could run plan also for absent state which isn't case in the current state. This could be achieved by running terraform plan with argument -destroy:

  -destroy            Select the "destroy" planning mode, which creates a plan
                            to destroy all objects currently managed by this
                            Terraform configuration instead of the usual behavior.

d) We could ran apply with -json argument in auto mode. I kinda expect it will provided more "machine" readable output. Additional benefit is that we could take outputs directly from apply and we don't have to run terraform output at the end. Some high-level examples:

# Parse error
$ terraform apply -json -auto-approve | jq -r '. | select(."@level"=="error").diagnostic.detail'

The root module input variable "api_token" is not set, and has no default value. Use a -var or -var-file command line argument to provide a value for this variable.

# Parse outputs
$ terraform apply -json -auto-approve | jq -r '.outputs'
null
null
null
null
{
  "users": {
    "sensitive": false,
    "action": "noop"
  }
}
null
{
  "users": {
    "sensitive": false,
    "type": [
      "object",
      {
        "phone": "string"
      }
    ],
    "value": {
      "phone": "arn:aws:iam::[reducted]:user/phone"
    }
  }
}

3) Questions to documentation / code.

a ) I'm kinda not sure if running init pose any risk. I'm using it very often and I never hit any issue. I mean it will not provision new infrastructure by default. Link to init documentation.

  force_init:
    description:
      - To avoid duplicating infra, if a state file can't be found this will
        force a C(terraform init). Generally, this should be turned off unless
        you intend to provision an entirely new Terraform deployment.

b) In a code you are creating plan_file as a temporary file when it isn't provided for apply (link). However the path to plan file isn't printed to user and the file isn't cleaned up at the end. This can technically reveal some information about infrastructure to any user - TMP directory can be read by any user in linux OS.

Looking forward to your replies.

Issue Type

Feature Idea

Component Name

terraform

Additional Information

No response

Code of Conduct

• [X] I agree to follow the Ansible Code of Conduct

[ansibullbot]

Files identified in the description:

• plugins/modules/terraform.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibullbot]

cc @m-yosefpor @rainerleber click here for bot help

[tima]

@findmyname666 Thanks for your interest and contribution here. Late last year we released the cloud.terraform collection which brought over the code here in community.general and then enhanced and supplemented it with additional content. We are beginning the process of adding cloud.terraform to the Ansible distro and deprecating what is in community.general. All of the Ansible team at Red Hat's efforts will be going into that new collection going forward. I recommend bringing your ideas and contribution there for consideration.

[findmyname666]

@tima thx I didn't know about it. I will check it ;)