hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
https://www.terraform.io/
Other
42.29k stars 9.48k forks source link

Feature Request - Report File #18411

Open trp956s opened 6 years ago

trp956s commented 6 years ago

0.11.7

It would be helpful for terraform to write out a formatted data file that gave:

  1. A list of Resources and actions (changed, added, deleted).
  2. The tfplan for these actions
  3. The actual outcome of the plan
  4. Total execution time -- I could provide this in my CI but would be nice to have already

EG a json file with the following:

{
  summary: {
    total_execution_time_in_seconds: 123456789 
  },
  tfplan_summary: {
    add: 1,
    destroy: 1,
    modify: 5
  },
  tfapply_summary: {
    added: 1,
    destroyed: 1,
    modified: 1
  },
  actions: [
  {
    name: 'tf-style-name-such-as-module.module-name.lambda.aws_lambda_function.lambda',
    resources_deleted: [],
    resources_added: [],
    resources_modified: [
      'full-name-of-lambda-on-aws-such-as-l1-east,
      'name-of-lambda-west-1',
    ]
  },
  {
    name: 'tf-style-name-such-as-module.deployment.aws_api_gateway_deployment.api_deployment',
    resources_deleted: [
      'full-name-of-gateway-on-aws'
    ],
    resources_added: [
      'full-name-of-gateway-on-aws'
    ],
    resources_modified: []
  }
  ]
}

I would include this as an artifact with my CI and use the report files to create a full summary that we could use to diagnose deployment performance, identify unnecessary resource re-deployments, and baseline how efficient our deployment is running.

Thank you. -T

apparentlymart commented 6 years ago

Hi @trp956s! Thanks for sharing this use-case.

We intend to gradually add more machine-readable output to Terraform over time, but we are intentionally postponing this for the moment because such a format would be a compatibility constraint that would make it harder to evolve Terraform.

Over the next few major releases we will be making some internal changes that should ultimately make it easier for us to specify, implement and commit to compatibility with a format like this.

withnale commented 6 years ago

I was about to write an issue but this is close to our short term need for reporting. We use terraform plan as an auditing tool and to be able to have these metrics easily available would be great.

Obviously, this also dovetails with the JSON output format terraform plan ticket.

apparentlymart commented 6 years ago

I suspect that a machine-readable rendering of a plan file will be the first change in this area to land, just because it's the one that can most easily be implemented alongside existing functionality without a lot of refactoring. We still need to complete some reorganization of how plans are structured in order to accommodate the changes coming in 0.12, but unless there's an "unknown unknown" I'm not aware of right now I expect we'll be able to offer an initially-experimental (i.e. possibility of minor changes) machine-readable plan in the near future, and then commit to compatibility with it once we've had an opportunity to respond to feedback from real-world usage and make sure it's fit for purpose.

Machine-readable versions of the entire output of an operation are more troublesome because they will tend to encode details about the entire workflow, and so once we get to that point it'll be much harder to make changes to the order Terraform does certain steps, etc. We still intend to do it, but we want to fully evaluate a set of potential workflow changes first to make sure we don't create a barrier to future development of those changes.