Terraform enables you to safely and predictably create, change, and improve infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.

Overview

Terraform

Terraform

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.

The key features of Terraform are:

  • Infrastructure as Code: Infrastructure is described using a high-level configuration syntax. This allows a blueprint of your datacenter to be versioned and treated as you would any other code. Additionally, infrastructure can be shared and re-used.

  • Execution Plans: Terraform has a "planning" step where it generates an execution plan. The execution plan shows what Terraform will do when you call apply. This lets you avoid any surprises when Terraform manipulates infrastructure.

  • Resource Graph: Terraform builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources. Because of this, Terraform builds infrastructure as efficiently as possible, and operators get insight into dependencies in their infrastructure.

  • Change Automation: Complex changesets can be applied to your infrastructure with minimal human interaction. With the previously mentioned execution plan and resource graph, you know exactly what Terraform will change and in what order, avoiding many possible human errors.

For more information, see the introduction section of the Terraform website.

Getting Started & Documentation

Documentation is available on the Terraform website:

If you're new to Terraform and want to get started creating infrastructure, please check out our Getting Started guides on HashiCorp's learning platform. There are also additional guides to continue your learning.

Show off your Terraform knowledge by passing a certification exam. Visit the certification page for information about exams and find study materials on HashiCorp's learning platform.

Developing Terraform

This repository contains only Terraform core, which includes the command line interface and the main graph engine. Providers are implemented as plugins, and Terraform can automatically download providers that are published on the Terraform Registry. HashiCorp develops some providers, and others are developed by other organizations. For more information, see Extending Terraform.

To learn more about compiling Terraform and contributing suggested changes, please refer to the contributing guide.

To learn more about how we handle bug reports, please read the bug triage guide.

License

Mozilla Public License v2.0

Issues
  • Support use cases with conditional logic

    Support use cases with conditional logic

    It's been important from the beginning that Terraform's configuration language is declarative, which has meant that the core team has intentionally avoided adding flow-control statements like conditionals and loops to the language.

    But in the real world, there are still plenty of perfectly reasonable scenarios that are difficult to express in the current version of Terraform without copious amounts of duplication because of the lack of conditionals. We'd like Terraform to support these use cases one way or another.

    I'm opening this issue to collect some real-world example where, as a config author, it seems like an if statement would really make things easier.

    Using these examples, we'll play around with different ideas to improve the tools Terraform provides to the config author in these scenarios.

    So please feel free to chime in with some specific examples - ideally with with blocks of Terraform configuration included. If you've got ideas for syntax or config language features that could form a solution, those are welcome here too.

    (No need to respond with just "+1" / :+1: on this thread, since it's an issue we're already aware is important.)

    enhancement core 
    opened by phinze 167
  • depends_on cannot be used in a module

    depends_on cannot be used in a module

    Hi there,

    Terraform Version

    0.8.0 rc1+

    Affected Resource(s)

    module

    Terraform Configuration Files

    module "legacy_site" {
      source = "../../../../../modules/site"
      name = "foo-site"
      health_check_target = "TCP:443"
      azs = "${var.azs}"
      instance_count = "${var.instance_count}"
      vpc = "apps"
      region = "${var.region}"
      environment = "${var.environment}"
      run_list = "hs_site_foo"
    
      #rds_complete = "${module.rds.db_instance_id}"
      #elasticache_cache_complete = "${module.elasticache_cache.elasticache_id}"
      #elasticache_sessions_complete = "${module.elasticache_sessions.elasticache_id}"
    
      depends_on = [
      "module.rds",
      "module.elasticache_sessions"
      ]
    
    }
    

    Debug Output

    Error loading Terraform: module root: module legacy_site: depends_on is not a valid parameter module root: module legacy_site: depends_on is not a valid parameter

    Expected Behavior

    I am trying to use the new depends_on instead of the above outputs, so I create and provision my app once I know database and caches are built.

    Actual Behavior

    Nothing as terraform errors out as above.

    Steps to Reproduce

    1. terraform apply

    References

    depends_on can reference modules. This allows a resource or output to depend on everything within a module. (#10076)

    enhancement config 
    opened by chrisrlong 136
  • Depends_on for module

    Depends_on for module

    Possible workarounds

    For module to module dependencies, this workaround by @phinze may help.

    Original problem

    This issue was promoted by this question on Google Groups.

    Terraform version: Terraform v0.3.7

    I have two terraform modules for creating a digital ocean VM and DNS records that are kept purposely modular so they can be reused by others in my organisation.

    I want to add a series of provisioners using local_exec after a VM has been created and DNS records made.

    Attempted solution

    I tried adding a provisioner directly to my terraform file (i.e. not in a resource) which gave an error.

    I then tried using the null_resource which worked but was executed at the wrong time as it didn't know to wait for the other modules to execute first.

    I then tried adding a depends_on attribute to the null resource using a reference to a module but this doesn't seem to be supported using this syntax:

    depends_on = ["module.module_name"]
    

    Expected result

    Either a way for a resource to depend on a module as a dependency or a way to "inject" (for lack of a better word) some provisioners for a resource into a module without having to make a custom version of that module (I realise that might be a separate issue but it would solve my original problem).

    Terraform config used

    # Terraform definition file - this file is used to describe the required infrastructure for this project.
    
    # Digital Ocean provider configuration
    
    provider "digitalocean" {
        token = "${var.digital_ocean_token}"
    }
    
    
    # Resources
    
    # 'whoosh-dev-web1' resource
    
    # VM
    
    module "whoosh-dev-web1-droplet" {
        source = "github.com/antarctica/terraform-module-digital-ocean-droplet?ref=v1.0.0"
        hostname = "whoosh-dev-web1"
        ssh_fingerprint = "${var.ssh_fingerprint}"
    }
    
    # DNS records (public, private and default [which is an APEX record and points to public])
    
    module "whoosh-dev-web1-records" {
        source = "github.com/antarctica/terraform-module-digital-ocean-records?ref=v0.1.1"
        hostname = "whoosh-dev-web1"
        machine_interface_ipv4_public = "${module.whoosh-dev-web1-droplet.ip_v4_address_public}"
        machine_interface_ipv4_private = "${module.whoosh-dev-web1-droplet.ip_v4_address_private}"
    }
    
    
    # Provisioning (using a fake resource as provisioners can't be first class objects)
    
    # Note: The "null_resource" is an undocumented feature and should not be relied upon.
    # See https://github.com/hashicorp/terraform/issues/580 for more information.
    
    resource "null_resource" "provisioning" {
    
        depends_on = ["module.whoosh-dev-web1-records"]
    
        # This replicates the provisioning steps performed by Vagrant
        provisioner "local-exec" {
            command = "ansible-playbook -i provisioning/development provisioning/bootstrap-digitalocean.yml"
        }
    }
    
    enhancement core thinking 
    opened by felnne 133
  • AWS Provider Coverage

    AWS Provider Coverage

    AWS Provider Coverage

    View this spreadsheet for a near-time summary of AWS resource coverage. If there's a resource you would like to see coverage for, just add your GitHub username to next to the resource. We will use the number of community upvotes in the spreadsheet to help prioritize our efforts.

    https://docs.google.com/spreadsheets/d/1yJKjLaTmkWcUS3T8TLwvXC6EBwNSpuQbIq0Y7OnMXhw/edit?usp=sharing

    enhancement provider/aws 
    opened by pearkes 126
  • terraform get: can't use variable in module source parameter?

    terraform get: can't use variable in module source parameter?

    I'm trying to avoid hard-coding module sources; the simplest approach would be:

    variable "foo_module_source" {
      default = "github.com/thisisme/terraform-foo-module"
    }
    
    module "foo" {
      source = "${var.foo_module_source}"
    }
    

    The result I get while attempting to run terraform get -update is

    Error loading Terraform: Error downloading modules: error downloading module 'file:///home/thisisme/terraform-env/${var.foo_module_source}': source path error: stat /home/thisisme/terraform-env/${var.foo_module_source}: no such file or directory
    
    enhancement thinking config 
    opened by amaczuga 124
  • OpenStack Provider

    OpenStack Provider

    UPDATE: 2/11/2015

    To Do:

    • [x] FWaaS
    • [x] Security Groups Update Issue
    • [x] Volume detachment from volume resource
    • [ ] os-floating-ip/ neutron floating IP issue
    • [ ] Refactor Security Group Rules and LB Members to their own files

    This PR is to create an OpenStack Provider. It uses the Gophercloud v1.0 library and currently supports the following resources:

    Compute v2

    • Server
    • Key Pair
    • Security Group
    • Boot From Volume
    • Metadata
    • Resizing (on flavor_id change)

    Networking v2

    • Network
    • Subnet

    Load Balancer v1

    • Pool (with members)
    • Virtual IP
    • Monitor

    Block Storage v1

    • Volume

    Object Storage v1

    • Container

    The PR includes acceptance tests for all the above resources (tested against DevStack), as well as documentation. In addition, the resources are versioned and region-based. Hopefully, this PR includes enough resources to close #51

    opened by jrperritt 98
  • Using element with splat reference should scope dependency to selected resource

    Using element with splat reference should scope dependency to selected resource

    I'm trying to setup a multi-node cluster with attached ebs volumes. An example below:

    resource "aws_instance" "nodes" {
        instance_type = "${var.model}"
        key_name = "${var.ec2_keypair}"
        ami = "${lookup(var.zk_amis, var.region)}"
        count = "${var.node_count}"
        vpc_security_group_ids = ["${aws_security_group.default.id}"]
        subnet_id = "${lookup(var.subnet_ids, element(keys(var.subnet_ids), count.index))}"
        associate_public_ip_address = true
        user_data = "${file("cloud_init")}"
        tags {
            Name = "${var.cluster_name}-${count.index}"
        }
    }
    
    resource "aws_ebs_volume" "node-ebs" {
        count = "${var.node-count}"
        availability_zone = "${element(keys(var.subnet_ids), count.index)}"
        size = 100
        tags {
            Name = "${var.cluster_name}-ebs-${count.index}"
        }
    }
    
    resource "aws_volume_attachment" "node-attach" {
        count = "${var.node_count}"
        device_name = "/dev/xvdh"
        volume_id = "${element(aws_ebs_volume.node-ebs.*.id, count.index)}"
        instance_id = "${element(aws_instance.nodes.*.id, count.index)}"
    }
    

    If a change happens to a single node (for instance if a single ec2 instance is terminated) ALL of the aws_volume_attachments are recreated.

    Clearly we would not want volume attachments to be removed in a production environment. Worse than that, in conjunction with #2957 you first must unmount these attachments before they can be recreated. This has the effect of making volume attachments only viable on brand new clusters.

    bug core 
    opened by kklipsch 95
  • A way to hide certain expected changes from the

    A way to hide certain expected changes from the "refresh" report ("Objects have changed outside of Terraform")

    After upgrading to 0.15.4 terraform reports changes that are ignored. It is exactly like commented here: https://github.com/hashicorp/terraform/issues/28776#issuecomment-846547594

    Terraform Version

    Terraform v0.15.4
    on darwin_amd64
    + provider registry.terraform.io/hashicorp/aws v3.42.0
    + provider registry.terraform.io/hashicorp/template v2.2.0
    

    Terraform Configuration Files

    
    resource "aws_batch_compute_environment" "batch_compute" {
      lifecycle {
        ignore_changes = [compute_resources[0].desired_vcpus]
      }
    
    ...
    
      compute_resources {
    ...
      }
    }
    
    resource "aws_db_instance" "postgres_db" {
      ...
    
      lifecycle {
        prevent_destroy = true
        ignore_changes = [latest_restorable_time]
      }
    }
    

    Output

    Note: Objects have changed outside of Terraform
    
    Terraform detected the following changes made outside of Terraform since the last "terraform apply":
    
      # module.db.aws_db_instance.postgres_db has been changed
      ~ resource "aws_db_instance" "postgres_db" {
            id                                    = "db"
          ~ latest_restorable_time                = "2021-05-25T10:24:14Z" -> "2021-05-25T10:29:14Z"
            name                                  = "db"
            tags                                  = {
                "Name" = "DatabaseServer"
            }
            # (47 unchanged attributes hidden)
    
            # (1 unchanged block hidden)
        }
      # module.batch_processor_dot_backend.aws_batch_compute_environment.batch_compute has been changed
      ~ resource "aws_batch_compute_environment" "batch_compute" {
            id                       = "batch-compute"
            tags                     = {}
            # (9 unchanged attributes hidden)
    
          ~ compute_resources {
              ~ desired_vcpus      = 0 -> 2
                tags               = {}
                # (9 unchanged attributes hidden)
            }
        }
    

    Expected Behavior

    No changes should be reported because they are listed in ignored changes.

    Actual Behavior

    Changes are reported.

    Steps to Reproduce

    Change any resource outside of terraform and see that terraform apply reports changed even when they should be ignored.

    Additional Context

    References

    • https://github.com/hashicorp/terraform/issues/28776
    • https://github.com/hashicorp/terraform/issues/28776#issuecomment-846547594
    • https://github.com/hashicorp/terraform/pull/28634#issuecomment-845934989
    enhancement cli v0.15 
    opened by petkaantonov 91
  • vSphere Provider: Mapping out the Next Steps

    vSphere Provider: Mapping out the Next Steps

    Wanted to kick off a higher level discussion of what needs to be done on the vSphere provider and in what order.

    • What are the important missing resources?
    • Are there any enhancements that need to be made to the existing functionality?
    • What do we need to do to ensure the provider works with all common versions of vSphere in the wild?

    Pinging @tkak and @mkuzmin to chime in as well as anybody else with interest/knowledge in the community.

    question provider/vsphere 
    opened by phinze 86
  • Destroy 'provisioner' for instance resources

    Destroy 'provisioner' for instance resources

    I would be great to have sort of a 'provisioner' for destroying an instance resource.

    Example: When creating a instance, I bootstrap it with chef and the node is registered with the chef server. Now I need a way of automatically deleting the node from the chef server after terraform destroys the instance.

    enhancement core 
    opened by kforsthoevel 86
  • Cannot use `terraform import` with module that has dynamic provider configuration

    Cannot use `terraform import` with module that has dynamic provider configuration

    Terraform Version

    Terraform v0.9.1

    Affected Resource(s)

    N/A

    Terraform Configuration Files

    # ./main.tf
    module "module_us_west_1" {
      source = "./module"
      region = "us-west-1"
    }
    
    # ./module/main.tf
    variable "region" {
      description = "AWS region for provider"
    }
    
    provider "aws" {
      region = "${var.region}"
    }
    
    resource "aws_cloudwatch_log_group" "rds_os" {
      name = "RDSOSMetrics"
      retention_in_days = 30
    }
    

    Debug Output

    https://gist.github.com/ff54870fee49636209ecfaa5de272175

    Panic Output

    N/A

    Expected Behavior

    Resource was imported

    Actual Behavior

    Error importing: 1 error(s) occurred:
    
    * module.module_us_west_1.provider.aws: 1:3: unknown variable accessed: var.region in:
    
    ${var.region}
    

    Steps to Reproduce

    1. terraform import module.module_us_west_1.aws_cloudwatch_log_group.rds_os "arn:aws:logs:us-west-1:FILTERED:log-group:RDSOSMetrics:*"

    Important Factoids

    N/A

    References

    N/A

    enhancement core cli 
    opened by jszwedko 83
  • configs: Fix module loader nil pointer panic

    configs: Fix module loader nil pointer panic

    In configurations which have already been initialized, updating the source of a non-root module call to an invalid value could cause a nil pointer panic. This commit fixes the bug and adds test coverage.

    Fixes #31056.

    config 1.2-backport 
    opened by alisdair 1
  • Add warning about drift to cloud block environment variables

    Add warning about drift to cloud block environment variables

    Related to https://github.com/hashicorp/terraform-website/pull/2310

    Add a warning about the potential of drift to the new section about non-interactive cloud block environment variables. Remote execution with the non-interactive component would require users to auto-approve plans. We provide more details about why this happens and suggest an alternative in the linked PR.

    opened by laurapacilio 0
  • If planning fails, show actions planned so far

    If planning fails, show actions planned so far

    Some planning errors are caused by values planned successfully upstream, and so showing the partial plan created so far might potentially provide some relevant context to help understand the error message being reported.

    Without showing this, today Terraform provides no way to inspect the actions planned so far, because they don't persist anywhere once Terraform exits.


    Terraform used the selected providers to generate the following execution plan.
    Resource actions are indicated with the following symbols:
      + create
    
    Terraform planned the following actions, but then encountered a problem:
    
      # null_resource.boop[0] will be created
      + resource "null_resource" "boop" {
          + id = (known after apply)
        }
    
    ╷
    │ Error: Resource precondition failed
    │ 
    │   on plan-time-fail-output.tf line 9, in resource "null_resource" "beep":
    │    9:       condition     = length(null_resource.boop) == 0
    │     ├────────────────
    │     │ null_resource.boop is tuple with 1 element
    │ 
    │ Too many boops.
    ╵
    
    enhancement cli plan-renderer 
    opened by apparentlymart 2
  • Crash when planning with an invalid module source in a parent module

    Crash when planning with an invalid module source in a parent module

    Terraform Version

    Terraform v1.1.9
    on linux_amd64
    + provider registry.terraform.io/hashicorp/aws v4.13.0
    + provider registry.terraform.io/hashicorp/external v2.2.2
    + provider registry.terraform.io/hashicorp/local v2.2.2
    + provider registry.terraform.io/hashicorp/null v3.1.1
    + provider registry.terraform.io/hashicorp/random v3.1.3
    

    Terraform Configuration Files

    I have a shell script instead of configuration files because the order in which the environments are created, and the order in which the configuration files are edited, is important to reproducing this.

    mkdir terraformbug && cd terraformbug
    echo 'resource "null_resource" "foo" {}\nmodule "foo" { source = "./submod2" }' > main.tf
    mkdir submod1
    echo 'module "foo" { source = "../" }' > submod1/main.tf
    mkdir submod2
    touch submod2/main.tf
    terraform init
    cd submod1
    terraform init
    echo 'resource "null_resource" "foo" {}\nmodule "foo" { source = "${path.module}/submod2" }' > ../main.tf
    terraform plan
    

    Debug Output

    Expected Behavior

    I would expect an error like Variables may not be used here. instead of a crash.

    Actual Behavior

    !!!!!!!!!!!!!!!!!!!!!!!!!!! TERRAFORM CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!
    
    Terraform crashed! This is always indicative of a bug within Terraform.
    Please report the crash with Terraform[1] so that we can fix this.
    
    When reporting bugs, please include your terraform version, the stack trace
    shown below, and any additional information which may help replicate the issue.
    
    [1]: https://github.com/hashicorp/terraform/issues
    
    !!!!!!!!!!!!!!!!!!!!!!!!!!! TERRAFORM CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!
    
    runtime error: invalid memory address or nil pointer dereference
    goroutine 54 [running]:
    runtime/debug.Stack()
    	/usr/local/go/src/runtime/debug/stack.go:24 +0x65
    runtime/debug.PrintStack()
    	/usr/local/go/src/runtime/debug/stack.go:16 +0x19
    github.com/hashicorp/terraform/internal/logging.PanicHandler()
    	/home/circleci/project/project/internal/logging/panic.go:55 +0x154
    panic({0x2328bc0, 0x418c6d0})
    	/usr/local/go/src/runtime/panic.go:1038 +0x215
    github.com/hashicorp/terraform/internal/configs/configload.(*Loader).moduleWalkerLoad(0xc00066c460, 0xc0001f7c20)
    	/home/circleci/project/project/internal/configs/configload/loader_load.go:64 +0x16c
    github.com/hashicorp/terraform/internal/configs/configload.(*Loader).makeModuleWalkerSnapshot.func1(0xc0001f7c20)
    	/home/circleci/project/project/internal/configs/configload/loader_snapshot.go:134 +0x54
    github.com/hashicorp/terraform/internal/configs.ModuleWalkerFunc.LoadModule(0x2301e80, 0xc00094dba0)
    	/home/circleci/project/project/internal/configs/config_build.go:131 +0x1f
    github.com/hashicorp/terraform/internal/configs.buildChildModules(0xc00032e8c0, {0x2c05840, 0xc000a80d80})
    	/home/circleci/project/project/internal/configs/config_build.go:69 +0x4bd
    github.com/hashicorp/terraform/internal/configs.buildChildModules(0xc00032e700, {0x2c05840, 0xc000a80d80})
    	/home/circleci/project/project/internal/configs/config_build.go:89 +0x77a
    github.com/hashicorp/terraform/internal/configs.BuildConfig(0xc000b7c370, {0x2c05840, 0xc000a80d80})
    	/home/circleci/project/project/internal/configs/config_build.go:24 +0x85
    github.com/hashicorp/terraform/internal/configs/configload.(*Loader).LoadConfigWithSnapshot(0xc00066c460, {0x26bcd4b, 0x1})
    	/home/circleci/project/project/internal/configs/configload/loader_snapshot.go:31 +0xbc
    github.com/hashicorp/terraform/internal/backend/local.(*Local).localRunDirect(0x27905f8, 0xc000528b40, 0xc000a952f0, 0x278b954, {0x2c6e728, 0xc00079b080})
    	/home/circleci/project/project/internal/backend/local/backend_local.go:135 +0x73
    github.com/hashicorp/terraform/internal/backend/local.(*Local).localRun(0xc000325cc0, 0xc000528b40)
    	/home/circleci/project/project/internal/backend/local/backend_local.go:98 +0x8d4
    github.com/hashicorp/terraform/internal/backend/local.(*Local).opPlan(0xc000325cc0, {0x2c4f078, 0xc000b7a200}, {0x2c4f078, 0xc000b7a240}, 0xc000528b40, 0xc000b7a1c0)
    	/home/circleci/project/project/internal/backend/local/backend_plan.go:58 +0x12b
    github.com/hashicorp/terraform/internal/backend/local.(*Local).Operation.func1()
    	/home/circleci/project/project/internal/backend/local/backend.go:323 +0xc3
    created by github.com/hashicorp/terraform/internal/backend/local.(*Local).Operation
    	/home/circleci/project/project/internal/backend/local/backend.go:316 +0x445
    

    Steps to Reproduce

    Additional Context

    References

    bug confirmed v1.1 v1.2 
    opened by Octogonapus 1
  • Terraform 1.1.0+ looks for other resource while targeting is in effect

    Terraform 1.1.0+ looks for other resource while targeting is in effect

    terraform targeting is not working starting 1.1.0 When i try to target a small subset of resources, it fails with or similar error witrh other resource.

     Error: Failed to decode resource from state
    │ 
    │ Error decoding "module.do2.module.rmq2.vsphere_virtual_machine.linux" from previous state: unsupported attribute "name"
    

    however with 1.0.11 it works fine. also if i run terraform plan using latest version of terraform without targeting it also calculates plan without problems.

    Terraform Version

    Terraform v1.0.11
    on linux_amd64
    + provider registry.terraform.io/hashicorp/vsphere v2.1.1
    
    Your version of Terraform is out of date! The latest version
    is 1.1.9. You can update by downloading from https://www.terraform.io/downloads.html
    

    Expected Behavior

    terraform calculates plan for selected subset of resources

    Actual Behavior

    terraform tries to decode other resources and fails

    Steps to Reproduce

    1. terraform init
    2. terraform plan --target=module.do3
    bug waiting for reproduction 
    opened by zalent 3
Releases(v1.2.0-rc2)
  • v1.2.0-rc2(May 11, 2022)

    1.2.0-rc2 (Unreleased)

    UPGRADE NOTES:

    • The official Linux packages for the v1.2 series now require Linux kernel version 2.6.32 or later.

    • When making outgoing HTTPS or other TLS connections as a client, Terraform now requires the server to support TLS v1.2. TLS v1.0 and v1.1 are no longer supported. Any safely up-to-date server should support TLS 1.2, and mainstream web browsers have required it since 2020.

    • When making outgoing HTTPS or other TLS connections as a client, Terraform will no longer accept CA certificates signed using the SHA-1 hash function. Publicly trusted Certificate Authorities have not issued SHA-1 certificates since 2015.

      (Note: the changes to Terraform's requirements when interacting with TLS servers apply only to requests made by Terraform CLI itself, such as provider/module installation and state storage requests. Terraform provider plugins include their own TLS clients which may have different requirements, and may add new requirements in their own releases, independently of Terraform CLI changes.)

    • If you use the third-party credentials helper plugin terraform-credentials-env, you should disable it as part of upgrading to Terraform v1.2 because similar functionality is now built in to Terraform itself.

      The new behavior supports the same environment variable naming scheme but has a difference in priority order from the credentials helper: TF_TOKEN_... environment variables will now take priority over credentials blocks in CLI configuration and credentials stored automatically by terraform login, which is not true for credentials provided by any credentials helper plugin. If you see Terraform using different credentials after upgrading, check to make sure you do not specify credentials for the same host in multiple locations.

      If you use the credentials helper in conjunction with the hashicorp/tfe Terraform provider to manage Terraform Cloud or Terraform Enterprise objects with Terraform, you should also upgrade to version 0.31 of that provider, which added the corresponding built-in support for these environment variables.

    NEW FEATURES:

    • precondition and postcondition check blocks for resources, data sources, and module output values: module authors can now document assumptions and assertions about configuration and state values. If these conditions are not met, Terraform will report a custom error message to the user and halt further evaluation.
    • You may specify remote network service credentials using an environment variable named after the host name with a TF_TOKEN_ prefix. For example, the value of a variable named TF_TOKEN_app_terraform_io will be used as a bearer authorization token when the CLI makes service requests to the host name "app.terraform.io".
    • replace_triggered_by is a new lifecycle argument which allows one to configure the replacement of a resource based on changes in a dependency.

    ENHANCEMENTS:

    • The "Invalid for_each argument" error message for unknown maps/sets now includes an additional paragraph to try to help the user notice they can move apply-time values into the map values instead of the map keys, and thus avoid the problem without resorting to -target. (#30327)
    • When showing the progress of a remote operation running in Terraform Cloud, Terraform CLI will include information about post-plan run tasks. (#30141)
    • Error messages for preconditions, postconditions, and custom variable validations are now evaluated as expressions, allowing interpolation of relevant values into the output. (#30613)
    • There are some small improvements to the error and warning messages Terraform will emit in the case of invalid provider configuration passing between modules. There are no changes to which situations will produce errors and warnings, but the messages now include additional information intended to clarify what problem Terraform is describing and how to address it. (#30639)
    • When running terraform plan, only show external changes which may have contributed to the current plan (#30486)
    • Terraform will now show a slightly different note in the plan output if a data resource read is deferred to the apply step due to it depending on a managed resource that has changes pending. (#30971)
    • Add TF_CLOUD_ORGANIZATION environment variable fallback for organization in the cloud configuration
    • Add TF_CLOUD_HOSTNAME environment variable fallback for hostname in the cloud configuration
    • TF_WORKSPACE can now be used to configure the workspaces attribute in your cloud configuration
    • When running on macOS, Terraform will now use platform APIs to validate certificates presented by TLS (HTTPS) servers. This may change exactly which root certificates Terraform will accept as valid. (#30768)
    • The AzureRM Backend now defaults to using MSAL (and Microsoft Graph) rather than ADAL (and Azure Active Directory Graph) for authentication. (#30891)
    • The AzureRM Backend now supports authenticating as a service principal using OpenID Connect. (#30936)
    • Show remote host in error message for clarity when installation of provider fails (#30810)
    • Terraform now prints a warning when adding an attribute to ignore_changes that is managed only by the provider (non-optional computed attribute). (#30517)
    • JSON plan and state output now includes exact type representations for output values. (#30945)
    • The ssh provisioner connection now supports SSH over HTTP proxy. (#30274)

    BUG FIXES:

    • Terraform now handles type constraints, nullability, and custom variable validation properly for root module variables. Previously there was an order of operations problem where the nullability and custom variable validation were checked too early, prior to dealing with the type constraints, and thus that logic could potentially "see" an incorrectly-typed value in spite of the type constraint, leading to incorrect errors. (#29959)
    • Applying the various type conversion functions like tostring, tonumber, etc to null will now return a null value of the intended type. For example, tostring(null) converts from a null value of an unknown type to a null value of string type. Terraform can often handle such conversions automatically when needed, but explicit annotations like this can help Terraform to understand author intent when inferring type conversions for complex-typed values. (#30879)
    • When reporting a type mismatch between the true and false results of a conditional expression when both results are of the same structural type kind (object/tuple, or a collection thereof), Terraform will no longer return a confusing message like "the types are object and object, respectively", and will instead attempt to explain how the two structural types differ. (#30920)
    • Terraform now outputs an error when cidrnetmask() is called with an IPv6 address, as it was previously documented to do. (#30703)
    • When performing advanced state management with the terraform state commands, Terraform now checks the required_version field in the configuration before proceeding. (#30511)
    • When rendering a diff, Terraform now quotes the name of any object attribute whose string representation is not a valid identifier. (#30766)
    • Terraform will prioritize local terraform variables over remote terraform variables in operations such as import, plan, refresh and apply for workspaces in local execution mode. This behavior applies to both remote backend and the cloud integration configuration. (#29972)
    • terraform show -json: JSON plan output now correctly maps aliased providers to their configurations, and includes the full provider source address alongside the short provider name. (#30138)
    • The local token configuration in the cloud and remote backend now has higher priority than the token specified in a CLI configuration. (#30664)
    • The cloud integration now gracefully exits when -input=false and an operation requires some user input.
    • The ssh client for provisioners is updated to use newer key algorithms, allowing it to connect to more recent versions of openssh servers (#30962)
    • A cancellation in the CLI may not be caught when using -auto-approve, causing unintended changes to be applied (#30979)
    • A provider failing to return a schema could result in a panic (#30987)
    Source code(tar.gz)
    Source code(zip)
  • v1.2.0-rc1(May 4, 2022)

    1.2.0-rc1 (Unreleased)

    UPGRADE NOTES:

    • The official Linux packages for the v1.2 series now require Linux kernel version 2.6.32 or later.

    • When making outgoing HTTPS or other TLS connections as a client, Terraform now requires the server to support TLS v1.2. TLS v1.0 and v1.1 are no longer supported. Any safely up-to-date server should support TLS 1.2, and mainstream web browsers have required it since 2020.

    • When making outgoing HTTPS or other TLS connections as a client, Terraform will no longer accept CA certificates signed using the SHA-1 hash function. Publicly trusted Certificate Authorities have not issued SHA-1 certificates since 2015.

      (Note: the changes to Terraform's requirements when interacting with TLS servers apply only to requests made by Terraform CLI itself, such as provider/module installation and state storage requests. Terraform provider plugins include their own TLS clients which may have different requirements, and may add new requirements in their own releases, independently of Terraform CLI changes.)

    • If you use the third-party credentials helper plugin terraform-credentials-env, you should disable it as part of upgrading to Terraform v1.2 because similar functionality is now built in to Terraform itself.

      The new behavior supports the same environment variable naming scheme but has a difference in priority order from the credentials helper: TF_TOKEN_... environment variables will now take priority over credentials blocks in CLI configuration and credentials stored automatically by terraform login, which is not true for credentials provided by any credentials helper plugin. If you see Terraform using different credentials after upgrading, check to make sure you do not specify credentials for the same host in multiple locations.

      If you use the credentials helper in conjunction with the hashicorp/tfe Terraform provider to manage Terraform Cloud or Terraform Enterprise objects with Terraform, you should also upgrade to version 0.31 of that provider, which added the corresponding built-in support for these environment variables.

    NEW FEATURES:

    • precondition and postcondition check blocks for resources, data sources, and module output values: module authors can now document assumptions and assertions about configuration and state values. If these conditions are not met, Terraform will report a custom error message to the user and halt further evaluation.
    • You may specify remote network service credentials using an environment variable named after the host name with a TF_TOKEN_ prefix. For example, the value of a variable named TF_TOKEN_app_terraform_io will be used as a bearer authorization token when the CLI makes service requests to the host name "app.terraform.io".
    • replace_triggered_by is a new lifecycle argument which allows one to configure the replacement of a resource based on changes in a dependency.

    ENHANCEMENTS:

    • The "Invalid for_each argument" error message for unknown maps/sets now includes an additional paragraph to try to help the user notice they can move apply-time values into the map values instead of the map keys, and thus avoid the problem without resorting to -target. (#30327)
    • When showing the progress of a remote operation running in Terraform Cloud, Terraform CLI will include information about post-plan run tasks. (#30141)
    • Error messages for preconditions, postconditions, and custom variable validations are now evaluated as expressions, allowing interpolation of relevant values into the output. (#30613)
    • There are some small improvements to the error and warning messages Terraform will emit in the case of invalid provider configuration passing between modules. There are no changes to which situations will produce errors and warnings, but the messages now include additional information intended to clarify what problem Terraform is describing and how to address it. (#30639)
    • When running terraform plan, only show external changes which may have contributed to the current plan (#30486)
    • Add TF_CLOUD_ORGANIZATION environment variable fallback for organization in the cloud configuration
    • Add TF_CLOUD_HOSTNAME environment variable fallback for hostname in the cloud configuration
    • TF_WORKSPACE can now be used to configure the workspaces attribute in your cloud configuration
    • When running on macOS, Terraform will now use platform APIs to validate certificates presented by TLS (HTTPS) servers. This may change exactly which root certificates Terraform will accept as valid. (#30768)
    • The AzureRM Backend now defaults to using MSAL (and Microsoft Graph) rather than ADAL (and Azure Active Directory Graph) for authentication. (#30891)
    • The AzureRM Backend now supports authenticating as a service principal using OpenID Connect. (#30936)
    • Show remote host in error message for clarity when installation of provider fails (#30810)
    • Terraform now prints a warning when adding an attribute to ignore_changes that is managed only by the provider (non-optional computed attribute). (#30517)
    • JSON plan and state output now includes exact type representations for output values. (#30945)
    • The ssh provisioner connection now supports SSH over HTTP proxy. (#30274)

    BUG FIXES:

    • Terraform now handles type constraints, nullability, and custom variable validation properly for root module variables. Previously there was an order of operations problem where the nullability and custom variable validation were checked too early, prior to dealing with the type constraints, and thus that logic could potentially "see" an incorrectly-typed value in spite of the type constraint, leading to incorrect errors. (#29959)
    • Applying the various type conversion functions like tostring, tonumber, etc to null will now return a null value of the intended type. For example, tostring(null) converts from a null value of an unknown type to a null value of string type. Terraform can often handle such conversions automatically when needed, but explicit annotations like this can help Terraform to understand author intent when inferring type conversions for complex-typed values. (#30879)
    • When reporting a type mismatch between the true and false results of a conditional expression when both results are of the same structural type kind (object/tuple, or a collection thereof), Terraform will no longer return a confusing message like "the types are object and object, respectively", and will instead attempt to explain how the two structural types differ. (#30920)
    • Terraform now outputs an error when cidrnetmask() is called with an IPv6 address, as it was previously documented to do. (#30703)
    • When performing advanced state management with the terraform state commands, Terraform now checks the required_version field in the configuration before proceeding. (#30511)
    • When rendering a diff, Terraform now quotes the name of any object attribute whose string representation is not a valid identifier. (#30766)
    • Terraform will prioritize local terraform variables over remote terraform variables in operations such as import, plan, refresh and apply for workspaces in local execution mode. This behavior applies to both remote backend and the cloud integration configuration. (#29972)
    • terraform show -json: JSON plan output now correctly maps aliased providers to their configurations, and includes the full provider source address alongside the short provider name. (#30138)
    • The local token configuration in the cloud and remote backend now has higher priority than the token specified in a CLI configuration. (#30664)
    • The cloud integration now gracefully exits when -input=false and an operation requires some user input.
    • The ssh client for provisioners is updated to use newer key algorithms, allowing it to connect to more recent versions of openssh servers (#30962)
    • A cancellation in the CLI may not be caught when using -auto-approve, causing unintended changes to be applied (#30979)
    • A provider failing to return a schema could result in a panic (#30987)
    Source code(tar.gz)
    Source code(zip)
  • v1.2.0-beta1(Apr 27, 2022)

    1.2.0 (Unreleased)

    UPGRADE NOTES:

    • The official Linux packages for the v1.2 series now require Linux kernel version 2.6.32 or later.

    • When making outgoing HTTPS or other TLS connections as a client, Terraform now requires the server to support TLS v1.2. TLS v1.0 and v1.1 are no longer supported. Any safely up-to-date server should support TLS 1.2, and mainstream web browsers have required it since 2020.

    • When making outgoing HTTPS or other TLS connections as a client, Terraform will no longer accept CA certificates signed using the SHA-1 hash function. Publicly trusted Certificate Authorities have not issued SHA-1 certificates since 2015.

      (Note: the changes to Terraform's requirements when interacting with TLS servers apply only to requests made by Terraform CLI itself, such as provider/module installation and state storage requests. Terraform provider plugins include their own TLS clients which may have different requirements, and may add new requirements in their own releases, independently of Terraform CLI changes.)

    • If you use the third-party credentials helper plugin terraform-credentials-env, you should disable it as part of upgrading to Terraform v1.2 because similar functionality is now built in to Terraform itself.

      The new behavior supports the same environment variable naming scheme but has a difference in priority order from the credentials helper: TF_TOKEN_... environment variables will now take priority over credentials blocks in CLI configuration and credentials stored automatically by terraform login, which is not true for credentials provided by any credentials helper plugin. If you see Terraform using different credentials after upgrading, check to make sure you do not specify credentials for the same host in multiple locations.

      If you use the credentials helper in conjunction with the hashicorp/tfe Terraform provider to manage Terraform Cloud or Terraform Enterprise objects with Terraform, you should also upgrade to version 0.31 of that provider, which added the corresponding built-in support for these environment variables.

    NEW FEATURES:

    • precondition and postcondition check blocks for resources, data sources, and module output values: module authors can now document assumptions and assertions about configuration and state values. If these conditions are not met, Terraform will report a custom error message to the user and halt further evaluation.
    • You may specify remote network service credentials using an environment variable named after the host name with a TF_TOKEN_ prefix. For example, the value of a variable named TF_TOKEN_app_terraform_io will be used as a bearer authorization token when the CLI makes service requests to the host name "app.terraform.io".
    • replace_triggered_by is a new lifecycle argument which allows one to configure the replacement of a resource based on changes in a dependency.

    ENHANCEMENTS:

    • The "Invalid for_each argument" error message for unknown maps/sets now includes an additional paragraph to try to help the user notice they can move apply-time values into the map values instead of the map keys, and thus avoid the problem without resorting to -target. (#30327)
    • When showing the progress of a remote operation running in Terraform Cloud, Terraform CLI will include information about post-plan run tasks. (#30141)
    • Error messages for preconditions, postconditions, and custom variable validations are now evaluated as expressions, allowing interpolation of relevant values into the output. (#30613)
    • There are some small improvements to the error and warning messages Terraform will emit in the case of invalid provider configuration passing between modules. There are no changes to which situations will produce errors and warnings, but the messages now include additional information intended to clarify what problem Terraform is describing and how to address it. (#30639)
    • When running terraform plan, only show external changes which may have contributed to the current plan (#30486)
    • Add TF_CLOUD_ORGANIZATION environment variable fallback for organization in the cloud configuration
    • Add TF_CLOUD_HOSTNAME environment variable fallback for hostname in the cloud configuration
    • TF_WORKSPACE can now be used to configure the workspaces attribute in your cloud configuration
    • When running on macOS, Terraform will now use platform APIs to validate certificates presented by TLS (HTTPS) servers. This may change exactly which root certificates Terraform will accept as valid. (#30768)
    • The AzureRM Backend now defaults to using MSAL (and Microsoft Graph) rather than ADAL (and Azure Active Directory Graph) for authentication. (#30891)
    • The AzureRM Backend now supports authenticating as a service principal using OpenID Connect. (#30936)
    • Show remote host in error message for clarity when installation of provider fails (#30810)
    • Terraform now prints a warning when adding an attribute to ignore_changes that is managed only by the provider (non-optional computed attribute). (#30517)
    • JSON plan and state output now includes exact type representations for output values. (#30945)

    BUG FIXES:

    • Terraform now handles type constraints, nullability, and custom variable validation properly for root module variables. Previously there was an order of operations problem where the nullability and custom variable validation were checked too early, prior to dealing with the type constraints, and thus that logic could potentially "see" an incorrectly-typed value in spite of the type constraint, leading to incorrect errors. (#29959)
    • Applying the various type conversion functions like tostring, tonumber, etc to null will now return a null value of the intended type. For example, tostring(null) converts from a null value of an unknown type to a null value of string type. Terraform can often handle such conversions automatically when needed, but explicit annotations like this can help Terraform to understand author intent when inferring type conversions for complex-typed values. (#30879)
    • When reporting a type mismatch between the true and false results of a conditional expression when both results are of the same structural type kind (object/tuple, or a collection thereof), Terraform will no longer return a confusing message like "the types are object and object, respectively", and will instead attempt to explain how the two structural types differ. (#30920)
    • Terraform now outputs an error when cidrnetmask() is called with an IPv6 address, as it was previously documented to do. (#30703)
    • When performing advanced state management with the terraform state commands, Terraform now checks the required_version field in the configuration before proceeding. (#30511)
    • When rendering a diff, Terraform now quotes the name of any object attribute whose string representation is not a valid identifier. (#30766)
    • Terraform will prioritize local terraform variables over remote terraform variables in operations such as import, plan, refresh and apply for workspaces in local execution mode. This behavior applies to both remote backend and the cloud integration configuration. (#29972)
    • terraform show -json: JSON plan output now correctly maps aliased providers to their configurations, and includes the full provider source address alongside the short provider name. (#30138)
    • The local token configuration in the cloud and remote backend now has higher priority than the token specified in a CLI configuration. (#30664)
    • The cloud integration now gracefully exits when -input=false and an operation requires some user input.
    Source code(tar.gz)
    Source code(zip)
  • v1.1.9(Apr 20, 2022)

    1.1.9 (April 20, 2022)

    BUG FIXES:

    • cli: Fix crash when using sensitive values in sets. (#30825)
    • cli: Fix double-quoted map keys when rendering a diff. (#30855)
    • core: Prevent errors when handling a data source with incompatible schema changes (#30830)

    ENHANCEMENTS:

    • cli: Terraform now supports run tasks, a Terraform Cloud integration for executing remote operations, for the post plan stage of a run.
    Source code(tar.gz)
    Source code(zip)
  • v1.2.0-alpha20220413(Apr 13, 2022)

    1.2.0 (Unreleased)

    UPGRADE NOTES:

    • The official Linux packages for the v1.2 series now require Linux kernel version 2.6.32 or later.
    • When making outgoing HTTPS or other TLS connections as a client, Terraform now requires the server to support TLS v1.2. TLS v1.0 and v1.1 are no longer supported. Any safely up-to-date server should support TLS 1.2, and mainstream web browsers have required it since 2020.
    • When making outgoing HTTPS or other TLS connections as a client, Terraform will no longer accept CA certificates signed using the SHA-1 hash function. Publicly trusted Certificate Authorities have not issued SHA-1 certificates since 2015.

    (Note: the changes to Terraform's requirements when interacting with TLS servers apply only to requests made by Terraform CLI itself, such as provider/module installation and state storage requests. Terraform provider plugins include their own TLS clients which may have different requirements, and may add new requirements in their own releases, independently of Terraform CLI changes.)

    NEW FEATURES:

    • precondition and postcondition check blocks for resources, data sources, and module output values: module authors can now document assumptions and assertions about configuration and state values. If these conditions are not met, Terraform will report a custom error message to the user and halt further evaluation.
    • Terraform now supports run tasks, a Terraform Cloud integration for executing remote operations, for the post plan stage of a run.

    ENHANCEMENTS:

    • The "Invalid for_each argument" error message for unknown maps/sets now includes an additional paragraph to try to help the user notice they can move apply-time values into the map values instead of the map keys, and thus avoid the problem without resorting to -target. (#30327)
    • When showing the progress of a remote operation running in Terraform Cloud, Terraform CLI will include information about post-plan run tasks. (#30141)
    • Error messages for preconditions, postconditions, and custom variable validations are now evaluated as expressions, allowing interpolation of relevant values into the output. (#30613)
    • There are some small improvements to the error and warning messages Terraform will emit in the case of invalid provider configuration passing between modules. There are no changes to which situations will produce errors and warnings, but the messages now include additional information intended to clarify what problem Terraform is describing and how to address it. (#30639)
    • When running terraform plan, only show external changes which may have contributed to the current plan (#30486)
    • Add TF_ORGANIZATION environment variable fallback for organization in the cloud configuration
    • Add TF_HOSTNAME environment variable fallback for hostname in the cloud configuration
    • When running on macOS, Terraform will now use platform APIs to validate certificates presented by TLS (HTTPS) servers. This may change exactly which root certificates Terraform will accept as valid. (#30768)

    BUG FIXES:

    • Terraform now handles type constraints, nullability, and custom variable validation properly for root module variables. Previously there was an order of operations problem where the nullability and custom variable validation were checked too early, prior to dealing with the type constraints, and thus that logic could potentially "see" an incorrectly-typed value in spite of the type constraint, leading to incorrect errors. (#29959)
    • terraform show -json: JSON plan output now correctly maps aliased providers to their configurations, and includes the full provider source address alongside the short provider name. (#30138)
    • Terraform now prints a warning when adding an attribute to ignore_changes that is managed only by the provider (non-optional computed attribute). (#30517)
    • Terraform will prioritize local terraform variables over remote terraform variables in operations such as import, plan, refresh and apply for workspaces in local execution mode. This behavior applies to both remote backend and the cloud integration configuration. (#29972)
    • Terraform now outputs an error when cidrnetmask() is called with an IPv6 address. (#30703)
    • When performing advanced state management with the terraform state commands, Terraform now checks the required_version field in the configuration before proceeding. (#30511)
    • When rendering a diff, Terraform now quotes the name of any object attribute whose string representation is not a valid identifier. (#30766)

    UPGRADE NOTES:

    • The Terraform Cloud integration relies on the Go-TFE SDK. Terraform has upgraded this dependency to use its new major version 1.0 [#30626]. Go-TFE v1.0.0 CHANGELOG.
    Source code(tar.gz)
    Source code(zip)
  • v1.1.8(Apr 7, 2022)

    1.1.8 (April 07, 2022)

    BUG FIXES:

    • cli: Fix missing identifying attributes (e.g. "id", "name") when displaying plan diffs with nested objects. (#30685)
    • functions: Fix error when sum() function is called with a collection of string-encoded numbers, such as sum(["1", "2", "3"]). (#30684)
    • When rendering a diff, Terraform now quotes the name of any object attribute whose string representation is not a valid identifier. (#30766)
    • Terraform will no longer crash in the terraform apply phase if an error occurs during backend configuration. (#30780)
    Source code(tar.gz)
    Source code(zip)
  • v1.2.0-alpha-20220328(Mar 28, 2022)

    1.2.0 (Unreleased)

    NEW FEATURES:

    • precondition and postcondition check blocks for resources, data sources, and module output values: module authors can now document assumptions and assertions about configuration and state values. If these conditions are not met, Terraform will report a custom error message to the user and halt further evaluation.
    • Terraform now supports run tasks, a Terraform Cloud integration for executing remote operations, for the post plan stage of a run.

    ENHANCEMENTS:

    • The "Invalid for_each argument" error message for unknown maps/sets now includes an additional paragraph to try to help the user notice they can move apply-time values into the map values instead of the map keys, and thus avoid the problem without resorting to -target. (#30327)
    • When showing the progress of a remote operation running in Terraform Cloud, Terraform CLI will include information about post-plan run tasks. (#30141)
    • Error messages for preconditions, postconditions, and custom variable validations are now evaluated as expressions, allowing interpolation of relevant values into the output. (#30613)
    • There are some small improvements to the error and warning messages Terraform will emit in the case of invalid provider configuration passing between modules. There are no changes to which situations will produce errors and warnings, but the messages now include additional information intended to clarify what problem Terraform is describing and how to address it. (#30639)
    • When running terraform plan, only show external changes which may have contributed to the current plan (#30486)

    BUG FIXES:

    • Terraform now handles type constraints, nullability, and custom variable validation properly for root module variables. Previously there was an order of operations problem where the nullability and custom variable validation were checked too early, prior to dealing with the type constraints, and thus that logic could potentially "see" an incorrectly-typed value in spite of the type constraint, leading to incorrect errors. (#29959)
    • terraform show -json: JSON plan output now correctly maps aliased providers to their configurations, and includes the full provider source address alongside the short provider name. (#30138)
    • Terraform now prints a warning when adding an attribute to ignore_changes that is managed only by the provider (non-optional computed attribute). (#30517)
    • Terraform will prioritize local terraform variables over remote terraform variables in operations such as import, plan, refresh and apply for workspaces in local execution mode. This behavior applies to both remote backend and the cloud integration configuration. (#29972)
    • Terraform now outputs an error when cidrnetmask() is called with an IPv6 address. (#30703)

    UPGRADE NOTES:

    • The Terraform Cloud integration relies on the Go-TFE SDK. Terraform has upgraded this dependency to use its new major version 1.0 [#30626]. Go-TFE v1.0.0 CHANGELOG.
    Source code(tar.gz)
    Source code(zip)
  • v1.1.7(Mar 2, 2022)

    1.1.7 (March 02, 2022)

    BUG FIXES:

    • terraform show -json: Improve performance for deeply-nested object values. The previous implementation was accidentally quadratic, which could result in very long execution time for generating JSON plans, and timeouts on Terraform Cloud and Terraform Enterprise. (#30561)
    • cloud: Update go-slug for terraform.tfstate exclusion to prevent a user from getting an error after migrating state to TFC.
    Source code(tar.gz)
    Source code(zip)
  • v1.1.6(Feb 16, 2022)

    1.1.6 (February 16, 2022)

    BUG FIXES:

    • cli: Prevent complex uses of the console-only type function. This function may only be used at the top level of console expressions, to display the type of a given value. Attempting to use this function in complex expressions will now display a diagnostic error instead of crashing. (#30476)
    • terraform state mv: Will now correctly exit with error code 1 when the specified resources cannot be found in state. Previously Terraform would display appropriate diagnostic errors, but exit successfully. (#29365)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.5(Feb 2, 2022)

    1.1.5 (February 02, 2022)

    ENHANCEMENTS:

    • backend/s3: Update AWS SDK to allow the use of the ap-southeast-3 region (#30363)

    BUG FIXES:

    • cli: Fix crash when using autocomplete with long commands, such as terraform workspace select (#30193)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.4(Jan 19, 2022)

    1.1.4 (January 19, 2022)

    BUG FIXES:

    • config: Non-nullable variables with null inputs were not given default values when checking validation statements (#30330)
    • config: Terraform will no longer incorrectly report "Cross-package move statement" when an external package has changed a resource from no count to using count, or vice-versa. (#30333)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.3(Jan 6, 2022)

    1.1.3 (January 06, 2022)

    BUG FIXES:

    • terraform init: Will now remove from the dependency lock file entries for providers not used in the current configuration. Previously it would leave formerly-used providers behind in the lock file, leading to "missing or corrupted provider plugins" errors when other commands verified the consistency of the installed plugins against the locked plugins. (#30192)
    • config: Fix panic when encountering an invalid provider block within a module (#30095)
    • config: Fix cycle error when the index of a module containing move statements is changed (#30232)
    • config: Fix inconsistent ordering with nested move operations (#30253)
    • config: Fix moved block refactoring to include nested modules (#30233)
    • functions: Redact sensitive values from function call error messages (#30067)
    • terraform show: Disable plan state lineage checks, ensuring that we can show plan files which were generated against non-default state files (#30205)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.2(Dec 17, 2021)

    1.1.2 (December 17, 2021)

    If you are using Terraform CLI v1.1.0 or v1.1.1, please upgrade to this new version as soon as possible.

    Terraform CLI v1.1.0 and v1.1.1 both have a bug where a failure to construct the apply-time graph can cause Terraform to incorrectly report success and save an empty state, effectively "forgetting" all existing infrastructure. Although configurations that already worked on previous releases should not encounter this problem, it's possible that incorrect future configuration changes would trigger this behavior during the apply step.

    BUG FIXES:

    • config: Fix panic when using -target in combination with moved blocks within modules (#30189)
    • core: Fix condition which could lead to an empty state being written when there is a failure building the apply graph (#30199)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.1(Dec 15, 2021)

    1.1.1 (December 15, 2021)

    If you are using Terraform CLI v1.1.0 or v1.1.1, please upgrade to the latest version as soon as possible.

    Terraform CLI v1.1.0 and v1.1.1 both have a bug where a failure to construct the apply-time graph can cause Terraform to incorrectly report success and save an empty state, effectively "forgetting" all existing infrastructure. Although configurations that already worked on previous releases should not encounter this problem, it's possible that incorrect future configuration changes would trigger this behavior during the apply step.


    BUG FIXES:

    • core: Fix crash with orphaned module instance due to changed count or for_each value (#30151)
    • core: Fix regression where some expressions failed during validation when referencing resources expanded with count or for_each (#30171)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Dec 8, 2021)

    1.1.0 (December 08, 2021)

    If you are using Terraform CLI v1.1.0 or v1.1.1, please upgrade to the latest version as soon as possible.

    Terraform CLI v1.1.0 and v1.1.1 both have a bug where a failure to construct the apply-time graph can cause Terraform to incorrectly report success and save an empty state, effectively "forgetting" all existing infrastructure. Although configurations that already worked on previous releases should not encounter this problem, it's possible that incorrect future configuration changes would trigger this behavior during the apply step.


    Terraform v1.1.0 is a new minor release, containing some new features and some bug fixes whose scope was too large for inclusion in a patch release.

    NEW FEATURES:

    • moved blocks for refactoring within modules: Module authors can now record in module source code whenever they've changed the address of a resource or resource instance, and then during planning Terraform will automatically migrate existing objects in the state to new addresses.

      This therefore avoids the need for users of a shared module to manually run terraform state mv after upgrading to a version of the module, as long as the change is expressible as static configuration. However, terraform state mv will remain available for use in more complex migration situations that are not well-suited to declarative configuration.

    • A new cloud block in the terraform settings block introduces a native Terraform Cloud integration for the CLI-driven run workflow.

      The Cloud integration includes several enhancements, including per-run variable support using the -var flag, the ability to map Terraform Cloud workspaces to the current configuration via Workspace Tags, and an improved user experience for Terraform Cloud and Enterprise users with actionable error messages and prompts.

    • terraform plan and terraform apply both now include additional annotations for resource instances planned for deletion to explain why Terraform has proposed that action.

      For example, if you change the count argument for a resource to a lower number then Terraform will now mention that as part of proposing to destroy any existing objects that exceed the new count.

    UPGRADE NOTES:

    This release is covered by the Terraform v1.0 Compatibility Promises, but does include some changes permitted within those promises as described below.

    • Terraform on macOS now requires macOS 10.13 High Sierra or later; Older macOS versions are no longer supported.

    • The terraform graph command no longer supports -type=validate and -type=eval options. The validate graph is always the same as the plan graph anyway, and the "eval" graph was just an implementation detail of the terraform console command. The default behavior of creating a plan graph should be a reasonable replacement for both of the removed graph modes. (Please note that terraform graph is not covered by the Terraform v1.0 compatibility promises, because its behavior inherently exposes Terraform Core implementation details, so we recommend it only for interactive debugging tasks and not for use in automation.)

    • terraform apply with a previously-saved plan file will now verify that the provider plugin packages used to create the plan fully match the ones used during apply, using the same checksum scheme that Terraform normally uses for the dependency lock file. Previously Terraform was checking consistency of plugins from a plan file using a legacy mechanism which covered only the main plugin executable, not any other files that might be distributed alongside in the plugin package.

      This additional check should not affect typical plugins that conform to the expectation that a plugin package's contents are immutable once released, but may affect a hypothetical in-house plugin that intentionally modifies extra files in its package directory somehow between plan and apply. If you have such a plugin, you'll need to change its approach to store those files in some other location separate from the package directory. This is a minor compatibility break motivated by increasing the assurance that plugins have not been inadvertently or maliciously modified between plan and apply.

    • terraform state mv will now error when legacy -backup or -backup-out options are used without the -state option on non-local backends. These options operate on a local state file only. Previously, these options were accepted but ignored silently when used with non-local backends.

    • In the AzureRM backend, the new opt-in option use_microsoft_graph switches to using MSAL authentication tokens and Microsoft Graph rather than using ADAL tokens and Azure Active Directory Graph, which is now deprecated by Microsoft. The new mode will become the default in Terraform v1.2, so please plan to migrate to using this setting and test with your own Azure AD tenant prior to the Terraform v1.2 release.

    ENHANCEMENTS:

    • config: Terraform now checks the syntax of and normalizes module source addresses (the source argument in module blocks) during configuration decoding rather than only at module installation time. This is largely just an internal refactoring, but a visible benefit of this change is that the terraform init messages about module downloading will now show the canonical module package address Terraform is downloading from, after interpreting the special shorthands for common cases like GitHub URLs. (#28854)
    • config: Variables can now be declared as "nullable", which defines whether a variable can be null within a module. Setting nullable = false ensures that a variable value will never be null, and may instead take on the variable's default value if the caller sets it explicitly to null. (#29832)
    • terraform plan and terraform apply: When Terraform plans to destroy a resource instance due to it no longer being declared in the configuration, the proposed plan output will now include a note hinting at what situation prompted that proposal, so you can more easily see what configuration change might avoid the object being destroyed. (#29637)
    • terraform plan and terraform apply: Terraform will now report explicitly in the UI if it automatically moves a resource instance to a new address as a result of adding or removing the count argument from an existing resource. For example, if you previously had resource "aws_subnet" "example" without count, you might have aws_subnet.example already bound to a remote object in your state. If you add count = 1 to that resource then Terraform would previously silently rebind the object to aws_subnet.example[0] as part of planning, whereas now Terraform will mention that it did so explicitly in the plan description. (#29605)
    • terraform workspace delete: will now allow deleting a workspace whose state contains only data resource instances and output values, without running terraform destroy first. Previously the presence of data resources would require using -force to override the safety check guarding against accidentally forgetting about remote objects, but a data resource is not responsible for the management of its associated remote object(s) and so there's no reason to require explicit deletion. (#29754)
    • terraform validate: Terraform now uses precise type information for resources during config validation, allowing more problems to be caught that that step rather than only during the planning step. (#29862)
    • provisioner/remote-exec and provisioner/file: When using SSH agent authentication mode on Windows, Terraform can now detect and use the Windows 10 built-in OpenSSH Client's SSH Agent, when available, in addition to the existing support for the third-party solution Pageant that was already supported. (#29747)
    • cli: terraform state mv will now return an error for -backup or -backup-out options used without the -state option, unless the working directory is initialized to use the local backend. Previously Terraform would silently ignore those options, since they are applicable only to the local backend. (#27908)
    • terraform console: now has a new type() function, available only in the interactive console, for inspecting the exact type of a particular value as an aid to debugging. (#28501)

    BUG FIXES:

    • config: ignore_changes = all now works in override files. (#29849)
    • config: Upgrading an unknown single value to a list using a splat expression now correctly returns an unknown value and type. Previously it would sometimes "overpromise" a particular return type, leading to an inconsistency error during the apply step. (#30062)
    • config: Terraform is now more precise in its detection of data resources that must be deferred to the apply step due to their depends_on arguments referring to not-yet-converged managed resources. (#29682)
    • config: ignore_changes can no longer cause a null map to be converted to an empty map, which would otherwise potentially cause surprising side-effects in provider logic. (#29928)
    • core: Provider configuration obtained from interactive prompts will now be merged properly with settings given in the configuration. Previously this merging was incorrect in some cases. (#29000)
    • terraform plan: Improved rendering of changes inside attributes that accept lists, sets, or maps of nested object types. (#29827, #29983, #29986)
    • terraform apply: Will no longer try to apply a stale plan that was generated against an originally-empty state. Previously this was an unintended exception to the rule that a plan can only be applied to the state snapshot it was generated against. (#29755)
    • terraform show -json: Attributes that are declared as using the legacy Attributes as Blocks behavior are now represented more faithfully in the JSON plan output. (#29522)
    • terraform init: Will now update the backend configuration hash value at a more approprimate time, to ensure properly restarting a backend migration process that failed on the first attempt. (#29860)
    • backend/oss: Flatten assume_role block arguments, so that they are more compatible with the terraform_remote_state data source. (#29307)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.0-rc1(Dec 1, 2021)

    1.1.0-rc1 (Unreleased)

    UPGRADE NOTES:

    • Terraform on macOS now requires macOS 10.13 High Sierra or later; Older macOS versions are no longer supported.

    • The terraform graph command no longer supports -type=validate and -type=eval options. The validate graph is always the same as the plan graph anyway, and the "eval" graph was just an implementation detail of the terraform console command. The default behavior of creating a plan graph should be a reasonable replacement for both of the removed graph modes. (Please note that terraform graph is not covered by the Terraform v1.0 compatibility promises, because its behavior inherently exposes Terraform Core implementation details, so we recommend it only for interactive debugging tasks and not for use in automation.)

    • terraform apply with a previously-saved plan file will now verify that the provider plugin packages used to create the plan fully match the ones used during apply, using the same checksum scheme that Terraform normally uses for the dependency lock file. Previously Terraform was checking consistency of plugins from a plan file using a legacy mechanism which covered only the main plugin executable, not any other files that might be distributed alongside in the plugin package.

      This additional check should not affect typical plugins that conform to the expectation that a plugin package's contents are immutable once released, but may affect a hypothetical in-house plugin that intentionally modifies extra files in its package directory somehow between plan and apply. If you have such a plugin, you'll need to change its approach to store those files in some other location separate from the package directory. This is a minor compatibility break motivated by increasing the assurance that plugins have not been inadvertently or maliciously modified between plan and apply.

    • terraform state mv will now error when legacy -backup or -backup-out options are used without the -state option on non-local backends. These options operate on a local state file only. Previously, these options were accepted but ignored silently when used with non-local backends.

    • backend/azurerm: a new opt-in flag use_microsoft_graph is available which switches to using MSAL authentication tokens and Microsoft Graph rather than using ADAL tokens and Azure Active Directory Graph which is now deprecated by Microsoft. This functionality is disabled by default but will be enabled by default in a future version of Terraform. We encourage you to configure and test this setting with your own Azure AD tenant prior to Terraform 1.2. (#29968)

    NEW FEATURES:

    • moved blocks for refactoring within modules: Module authors can now record in module source code whenever they've changed the address of a resource or resource instance, and then during planning Terraform will automatically migrate existing objects in the state to new addresses.

      This therefore avoids the need for module users to manually run terraform state mv after upgrading to a newer module version, as long as the change is expressible as static configuration. However, terraform state mv remains available for use in more complex migration situations that are not well-suited to declarative configuration.

    • A new cloud option in the terraform settings block adds a more native integration for Terraform Cloud and its CLI-driven run workflow. The Cloud integration includes several enhancements, including per-run variable support using the -var flag, the ability to map Terraform Cloud workspaces to the current configuration via Workspace Tags, and an improved user experience for Terraform Cloud/Enterprise users with actionable error messages and prompts. (#29826)

    • terraform plan and terraform apply: When Terraform plans to destroy a resource instance due to it no longer being declared in the configuration, the proposed plan output will now include a note hinting at what situation prompted that proposal, so you can more easily see what configuration change might avoid the object being destroyed. (#29637)

    • terraform plan and terraform apply: When Terraform automatically moves a singleton resource instance to index zero or vice-versa in response to adding or removing count, it'll report explicitly that it did so as part of the plan output. (#29605)

    • config: a new type() function, available only in terraform console. (#28501)

    ENHANCEMENTS:

    • config: Terraform now checks the syntax of and normalizes module source addresses (the source argument in module blocks) during configuration decoding rather than only at module installation time. This is largely just an internal refactoring, but a visible benefit of this change is that the terraform init messages about module downloading will now show the canonical module package address Terraform is downloading from, after interpreting the special shorthands for common cases like GitHub URLs. (#28854)
    • config: A new variable attribute nullable, which defines whether a variable can be null within a module. Setting nullable to false ensures that a variable value will not be null, and that a non-null default is used when null is given as a module argument (#29832)
    • terraform plan and terraform apply: Terraform will now report explicitly in the UI if it automatically moves a resource instance to a new address as a result of adding or removing the count argument from an existing resource. For example, if you previously had resource "aws_subnet" "example" without count, you might have aws_subnet.example already bound to a remote object in your state. If you add count = 1 to that resource then Terraform would previously silently rebind the object to aws_subnet.example[0] as part of planning, whereas now Terraform will mention that it did so explicitly in the plan description. (#29605)
    • terraform workspace delete: will now allow deleting a workspace whose state contains only data resource instances and output values, without running terraform destroy first. Previously the presence of data resources would require using -force to override the safety check guarding against accidentally forgetting about remote objects, but a data resource is not responsible for the management of its associated remote object(s) anyway. (#29754)
    • provisioner/remote-exec and provisioner/file: When using SSH agent authentication mode on Windows, Terraform can now detect and use the Windows 10 built-in OpenSSH Client's SSH Agent, when available, in addition to the existing support for the third-party solution Pageant that was already supported. (#29747)
    • cli: terraform state mv will now error when legacy -backup or -backup-out options are used without the -state option on non-local backends (#27908)

    BUG FIXES:

    • backend/oss: Flatten assume_role block attributes, so that they may be more easily represented in a compatible way with terraform_remote_state (#29307)
    • config: Fixed a bug in which ignore_changes = all would not work in override files (#29849)
    • config: Upgrading an unknown single value to a list using a splat expression must return an unknown value and type (#30062)
    • core: Use more precise typing information of resources during config validation (#29862)
    • core: Fixed an issue where provider configuration input variables were not properly merging with values in configuration (#29000)
    • core: Reduce scope of dependencies that may defer reading of data sources when using depends_on or directly referencing managed resources (#29682)
    • core: ignore_changes could cause a null map to be converted to an empty map (#29928)
    • cli: Blocks using SchemaConfigModeAttr in the provider SDK can now represented in the plan json output (#29522)
    • cli: Prevent applying a stale planfile when there was no previous state (#29755)
    • cli: Improve list nested attribute rendering (#29827)
    • cli: Improve set nested attribute rendering (#29983)
    • cli: Improve map and single nested attribute rendering (#29986)
    • command: Fixed an issue where the backend cache hash value was being updated too early in backend initialization/migrate flows, causing situations where init would not properly restart a backend migration process if that process failed previously. (#29860)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.0-beta2(Nov 17, 2021)

    1.1.0 (Unreleased)

    UPGRADE NOTES:

    • Terraform on macOS now requires macOS 10.13 High Sierra or later; Older macOS versions are no longer supported.

    • The terraform graph command no longer supports -type=validate and -type=eval options. The validate graph is always the same as the plan graph anyway, and the "eval" graph was just an implementation detail of the terraform console command. The default behavior of creating a plan graph should be a reasonable replacement for both of the removed graph modes. (Please note that terraform graph is not covered by the Terraform v1.0 compatibility promises, because its behavior inherently exposes Terraform Core implementation details, so we recommend it only for interactive debugging tasks and not for use in automation.)

    • terraform apply with a previously-saved plan file will now verify that the provider plugin packages used to create the plan fully match the ones used during apply, using the same checksum scheme that Terraform normally uses for the dependency lock file. Previously Terraform was checking consistency of plugins from a plan file using a legacy mechanism which covered only the main plugin executable, not any other files that might be distributed alongside in the plugin package.

      This additional check should not affect typical plugins that conform to the expectation that a plugin package's contents are immutable once released, but may affect a hypothetical in-house plugin that intentionally modifies extra files in its package directory somehow between plan and apply. If you have such a plugin, you'll need to change its approach to store those files in some other location separate from the package directory. This is a minor compatibility break motivated by increasing the assurance that plugins have not been inadvertently or maliciously modified between plan and apply.

    • terraform state mv will now error when legacy -backup or -backup-out options are used without the -state option on non-local backends. These options operate on a local state file only. Previously, these options were accepted but ignored silently when used with non-local backends.

    • backend/azurerm: a new opt-in flag use_microsoft_graph is available which switches to using MSAL authentication tokens and Microsoft Graph rather than using ADAL tokens and Azure Active Directory Graph which is now deprecated by Microsoft. This functionality is disabled by default but will be enabled by default in a future version of Terraform. We encourage you to configure and test this setting with your own Azure AD tenant prior to Terraform 1.2. (#29968)

    NEW FEATURES:

    • moved blocks for refactoring within modules: Module authors can now record in module source code whenever they've changed the address of a resource or resource instance, and then during planning Terraform will automatically migrate existing objects in the state to new addresses.

      This therefore avoids the need for module users to manually run terraform state mv after upgrading to a newer module version, as long as the change is expressible as static configuration. However, terraform state mv remains available for use in more complex migration situations that are not well-suited to declarative configuration.

    • A new cloud option in the terraform settings block adds a more native integration for Terraform Cloud and its CLI-driven run workflow. The Cloud integration includes several enhancements, including per-run variable support using the -var flag, the ability to map Terraform Cloud workspaces to the current configuration via Workspace Tags, and an improved user experience for Terraform Cloud/Enterprise users with actionable error messages and prompts. (#29826)

    • terraform plan and terraform apply: When Terraform plans to destroy a resource instance due to it no longer being declared in the configuration, the proposed plan output will now include a note hinting at what situation prompted that proposal, so you can more easily see what configuration change might avoid the object being destroyed. (#29637)

    • terraform plan and terraform apply: When Terraform automatically moves a singleton resource instance to index zero or vice-versa in response to adding or removing count, it'll report explicitly that it did so as part of the plan output. (#29605)

    • config: a new type() function, available only in terraform console. (#28501)

    ENHANCEMENTS:

    • config: Terraform now checks the syntax of and normalizes module source addresses (the source argument in module blocks) during configuration decoding rather than only at module installation time. This is largely just an internal refactoring, but a visible benefit of this change is that the terraform init messages about module downloading will now show the canonical module package address Terraform is downloading from, after interpreting the special shorthands for common cases like GitHub URLs. (#28854)
    • config: A new variable attribute nullable, which defines whether a variable can be null within a module. Setting nullable to false ensures that a variable value will not be null, and that a non-null default is used when null is given as a module argument (#29832)
    • terraform plan and terraform apply: Terraform will now report explicitly in the UI if it automatically moves a resource instance to a new address as a result of adding or removing the count argument from an existing resource. For example, if you previously had resource "aws_subnet" "example" without count, you might have aws_subnet.example already bound to a remote object in your state. If you add count = 1 to that resource then Terraform would previously silently rebind the object to aws_subnet.example[0] as part of planning, whereas now Terraform will mention that it did so explicitly in the plan description. (#29605)
    • terraform workspace delete: will now allow deleting a workspace whose state contains only data resource instances and output values, without running terraform destroy first. Previously the presence of data resources would require using -force to override the safety check guarding against accidentally forgetting about remote objects, but a data resource is not responsible for the management of its associated remote object(s) anyway. (#29754)
    • provisioner/remote-exec and provisioner/file: When using SSH agent authentication mode on Windows, Terraform can now detect and use the Windows 10 built-in OpenSSH Client's SSH Agent, when available, in addition to the existing support for the third-party solution Pageant that was already supported. (#29747)
    • cli: terraform state mv will now error when legacy -backup or -backup-out options are used without the -state option on non-local backends (#27908)

    BUG FIXES:

    • backend/oss: Flatten assume_role block attributes, so that they may be more easily represented in a compatible way with terraform_remote_state (#29307)
    • config: Fixed a bug in which ignore_changes = all would not work in override files (#29849)
    • core: Use more precise typing information of resources during config validation (#29862)
    • core: Fixed an issue where provider configuration input variables were not properly merging with values in configuration (#29000)
    • core: Reduce scope of dependencies that may defer reading of data sources when using depends_on or directly referencing managed resources (#29682)
    • core: ignore_changes could cause a null map to be converted to an empty map (#29928)
    • cli: Blocks using SchemaConfigModeAttr in the provider SDK can now represented in the plan json output (#29522)
    • cli: Prevent applying a stale planfile when there was no previous state (#29755)
    • cli: Improve list nested attribute rendering (#29827)
    • command: Fixed an issue where the backend cache hash value was being updated too early in backend initialization/migrate flows, causing situations where init would not properly restart a backend migration process if that process failed previously. (#29860)
    Source code(tar.gz)
    Source code(zip)
  • v1.0.11(Nov 10, 2021)

    1.0.11 (November 10, 2021)

    ENHANCEMENTS:

    • backend/oss: Added support for sts_endpoint (#29841)

    BUG FIXES:

    • config: Fixed a bug in which ignore_changes = all would not work in override files (#29849)
    • config: Numbers are now compared for equality based on their protocol representation, eliminating unexpected changes due to small precision errors (#29864)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.0-beta1(Nov 4, 2021)

    1.1.0 (Unreleased)

    UPGRADE NOTES:

    • Terraform on macOS now requires macOS 10.13 High Sierra or later; Older macOS versions are no longer supported.

    • The terraform graph command no longer supports -type=validate and -type=eval options. The validate graph is always the same as the plan graph anyway, and the "eval" graph was just an implementation detail of the terraform console command. The default behavior of creating a plan graph should be a reasonable replacement for both of the removed graph modes. (Please note that terraform graph is not covered by the Terraform v1.0 compatibility promises, because its behavior inherently exposes Terraform Core implementation details, so we recommend it only for interactive debugging tasks and not for use in automation.)

    • terraform apply with a previously-saved plan file will now verify that the provider plugin packages used to create the plan fully match the ones used during apply, using the same checksum scheme that Terraform normally uses for the dependency lock file. Previously Terraform was checking consistency of plugins from a plan file using a legacy mechanism which covered only the main plugin executable, not any other files that might be distributed alongside in the plugin package.

      This additional check should not affect typical plugins that conform to the expectation that a plugin package's contents are immutable once released, but may affect a hypothetical in-house plugin that intentionally modifies extra files in its package directory somehow between plan and apply. If you have such a plugin, you'll need to change its approach to store those files in some other location separate from the package directory. This is a minor compatibility break motivated by increasing the assurance that plugins have not been inadvertently or maliciously modified between plan and apply.

    NEW FEATURES:

    • moved blocks for refactoring within modules: Module authors can now record in module source code whenever they've changed the address of a resource or resource instance, and then during planning Terraform will automatically migrate existing objects in the state to new addresses.

      This therefore avoids the need for module users to manually run terraform state mv after upgrading to a newer module version, as long as the change is expressible as static configuration. However, terraform state mv remains available for use in more complex migration situations that are not well-suited to declarative configuration.

    • A new cloud option in the terraform settings block adds a more native integration for Terraform Cloud and its CLI-driven run workflow. The Cloud integration includes several enhancements, including per-run variable support using the -var flag, the ability to map Terraform Cloud workspaces to the current configuration via Workspace Tags, and an improved user experience for Terraform Cloud/Enterprise users with actionable error messages and prompts. (#29826)

    • terraform plan and terraform apply: When Terraform plans to destroy a resource instance due to it no longer being declared in the configuration, the proposed plan output will now include a note hinting at what situation prompted that proposal, so you can more easily see what configuration change might avoid the object being destroyed. (#29637)

    • terraform plan and terraform apply: When Terraform automatically moves a singleton resource instance to index zero or vice-versa in response to adding or removing count, it'll report explicitly that it did so as part of the plan output. (#29605)

    • config: a new type() function, available only in terraform console. (#28501)

    ENHANCEMENTS:

    • config: Terraform now checks the syntax of and normalizes module source addresses (the source argument in module blocks) during configuration decoding rather than only at module installation time. This is largely just an internal refactoring, but a visible benefit of this change is that the terraform init messages about module downloading will now show the canonical module package address Terraform is downloading from, after interpreting the special shorthands for common cases like GitHub URLs. (#28854)
    • config: A new variable attribute nullable, which defines whether a variable can be null within a module. Setting nullable to false ensures that a variable value will not be null, and that a non-null default is used when null is given as a module argument (#29832)
    • terraform plan and terraform apply: Terraform will now report explicitly in the UI if it automatically moves a resource instance to a new address as a result of adding or removing the count argument from an existing resource. For example, if you previously had resource "aws_subnet" "example" without count, you might have aws_subnet.example already bound to a remote object in your state. If you add count = 1 to that resource then Terraform would previously silently rebind the object to aws_subnet.example[0] as part of planning, whereas now Terraform will mention that it did so explicitly in the plan description. (#29605)
    • terraform workspace delete: will now allow deleting a workspace whose state contains only data resource instances and output values, without running terraform destroy first. Previously the presence of data resources would require using -force to override the safety check guarding against accidentally forgetting about remote objects, but a data resource is not responsible for the management of its associated remote object(s) anyway. (#29754)
    • provisioner/remote-exec and provisioner/file: When using SSH agent authentication mode on Windows, Terraform can now detect and use the Windows 10 built-in OpenSSH Client's SSH Agent, when available, in addition to the existing support for the third-party solution Pageant that was already supported. (#29747)

    BUG FIXES:

    • backend/oss: Flatten assume_role block attributes, so that they may be more easily represented in a compatible way with terraform_remote_state (#29307)
    • config: Fixed a bug in which ignore_changes = all would not work in override files (#29849)
    • core: Use more precise typing information of resources during config validation (#29862)
    • core: Fixed an issue where provider configuration input variables were not properly merging with values in configuration (#29000)
    • core: Reduce scope of dependencies that may defer reading of data sources when using depends_on or directly referencing managed resources (#29682)
    • cli: Blocks using SchemaConfigModeAttr in the provider SDK can now represented in the plan json output (#29522)
    • cli: Prevent applying a stale planfile when there was no previous state (#29755)
    • cli: Improve list nested attribute rendering (#29827)
    • command: Fixed an issue where the backend cache hash value was being updated too early in backend initialization/migrate flows, causing situations where init would not properly restart a backend migration process if that process failed previously. (#29860)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.0-alpha20211029(Oct 29, 2021)

    1.1.0 (Unreleased)

    UPGRADE NOTES:

    • Terraform on macOS now requires macOS 10.13 High Sierra or later; Older macOS versions are no longer supported.

    • The terraform graph command no longer supports -type=validate and -type=eval options. The validate graph is always the same as the plan graph anyway, and the "eval" graph was just an implementation detail of the terraform console command. The default behavior of creating a plan graph should be a reasonable replacement for both of the removed graph modes. (Please note that terraform graph is not covered by the Terraform v1.0 compatibility promises, because its behavior inherently exposes Terraform Core implementation details, so we recommend it only for interactive debugging tasks and not for use in automation.)

    • terraform apply with a previously-saved plan file will now verify that the provider plugin packages used to create the plan fully match the ones used during apply, using the same checksum scheme that Terraform normally uses for the dependency lock file. Previously Terraform was checking consistency of plugins from a plan file using a legacy mechanism which covered only the main plugin executable, not any other files that might be distributed alongside in the plugin package.

      This additional check should not affect typical plugins that conform to the expectation that a plugin package's contents are immutable once released, but may affect a hypothetical in-house plugin that intentionally modifies extra files in its package directory somehow between plan and apply. If you have such a plugin, you'll need to change its approach to store those files in some other location separate from the package directory. This is a minor compatibility break motivated by increasing the assurance that plugins have not been inadvertently or maliciously modified between plan and apply.

    NEW FEATURES:

    • A new cloud option in the terraform settings block adds a more native integration for Terraform Cloud and its CLI-driven run workflow. The Cloud integration includes several enhancements, including per-run variable support using the -var flag, the ability to map Terraform Cloud workspaces to the current configuration via Workspace Tags, and an improved user experience for Terraform Cloud/Enterprise users with actionable error messages and prompts. (#29826)
    • terraform plan and terraform apply: When Terraform plans to destroy a resource instance due to it no longer being declared in the configuration, the proposed plan output will now include a note hinting at what situation prompted that proposal, so you can more easily see what configuration change might avoid the object being destroyed. (#29637)
    • terraform plan and terraform apply: When Terraform automatically moves a singleton resource instance to index zero or vice-versa in response to adding or removing count, it'll report explicitly that it did so as part of the plan output. (#29605)
    • config: a new type() function, available only in terraform console. (#28501)

    ENHANCEMENTS:

    • config: Terraform now checks the syntax of and normalizes module source addresses (the source argument in module blocks) during configuration decoding rather than only at module installation time. This is largely just an internal refactoring, but a visible benefit of this change is that the terraform init messages about module downloading will now show the canonical module package address Terraform is downloading from, after interpreting the special shorthands for common cases like GitHub URLs. (#28854)
    • terraform plan and terraform apply: Terraform will now report explicitly in the UI if it automatically moves a resource instance to a new address as a result of adding or removing the count argument from an existing resource. For example, if you previously had resource "aws_subnet" "example" without count, you might have aws_subnet.example already bound to a remote object in your state. If you add count = 1 to that resource then Terraform would previously silently rebind the object to aws_subnet.example[0] as part of planning, whereas now Terraform will mention that it did so explicitly in the plan description. (#29605)
    • terraform workspace delete: will now allow deleting a workspace whose state contains only data resource instances and output values, without running terraform destroy first. Previously the presence of data resources would require using -force to override the safety check guarding against accidentally forgetting about remote objects, but a data resource is not responsible for the management of its associated remote object(s) anyway. (#29754)
    • provisioner/remote-exec and provisioner/file: When using SSH agent authentication mode on Windows, Terraform can now detect and use the Windows 10 built-in OpenSSH Client's SSH Agent, when available, in addition to the existing support for the third-party solution Pageant that was already supported. (#29747)

    BUG FIXES:

    • core: Fixed an issue where provider configuration input variables were not properly merging with values in configuration (#29000)
    • core: Reduce scope of dependencies that may defer reading of data sources when using depends_on or directly referencing managed resources (#29682)
    • cli: Blocks using SchemaConfigModeAttr in the provider SDK can now represented in the plan json output (#29522)
    • cli: Prevent applying a stale planfile when there was no previous state (#29755)
    Source code(tar.gz)
    Source code(zip)
  • v1.0.10(Oct 28, 2021)

    1.0.10 (October 28, 2021)

    BUG FIXES:

    • backend/oss: Fix panic when there's an error looking up OSS endpoints (#29784)
    • backend/remote: Fix version check when migrating state (#29793)
    • cli: Restore -lock and -lock-timeout flags for the init command, which were removed in 0.15.0 (#29773)
    • cli: Fix bug where terraform init -input=false would hang waiting for user input to choose a workspace (#29805)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.0-alpha20211020(Oct 20, 2021)

    1.1.0 (Unreleased)

    UPGRADE NOTES:

    • Terraform on macOS now requires macOS 10.13 High Sierra or later; Older macOS versions are no longer supported.

    • The terraform graph command no longer supports -type=validate and -type=eval options. The validate graph is always the same as the plan graph anyway, and the "eval" graph was just an implementation detail of the terraform console command. The default behavior of creating a plan graph should be a reasonable replacement for both of the removed graph modes. (Please note that terraform graph is not covered by the Terraform v1.0 compatibility promises, because its behavior inherently exposes Terraform Core implementation details, so we recommend it only for interactive debugging tasks and not for use in automation.)

    • terraform apply with a previously-saved plan file will now verify that the provider plugin packages used to create the plan fully match the ones used during apply, using the same checksum scheme that Terraform normally uses for the dependency lock file. Previously Terraform was checking consistency of plugins from a plan file using a legacy mechanism which covered only the main plugin executable, not any other files that might be distributed alongside in the plugin package.

      This additional check should not affect typical plugins that conform to the expectation that a plugin package's contents are immutable once released, but may affect a hypothetical in-house plugin that intentionally modifies extra files in its package directory somehow between plan and apply. If you have such a plugin, you'll need to change its approach to store those files in some other location separate from the package directory. This is a minor compatibility break motivated by increasing the assurance that plugins have not been inadvertently or maliciously modified between plan and apply.

    • Earlier v1.1 alpha releases had an experimental new command terraform add. We've removed that feature and plan to reconsider it before offering an alternative in a later release.

    NEW FEATURES:

    • terraform plan and terraform apply: When Terraform plans to destroy a resource instance due to it no longer being declared in the configuration, the proposed plan output will now include a note hinting at what situation prompted that proposal, so you can more easily see what configuration change might avoid the object being destroyed. (#29637)
    • terraform plan and terraform apply: When Terraform automatically moves a singleton resource instance to index zero or vice-versa in response to adding or removing count, it'll report explicitly that it did so as part of the plan output. (#29605)
    • config: a new type() function, available only in terraform console. (#28501)

    ENHANCEMENTS:

    • config: Terraform now checks the syntax of and normalizes module source addresses (the source argument in module blocks) during configuration decoding rather than only at module installation time. This is largely just an internal refactoring, but a visible benefit of this change is that the terraform init messages about module downloading will now show the canonical module package address Terraform is downloading from, after interpreting the special shorthands for common cases like GitHub URLs. (#28854)
    • terraform plan and terraform apply: Terraform will now report explicitly in the UI if it automatically moves a resource instance to a new address as a result of adding or removing the count argument from an existing resource. For example, if you previously had resource "aws_subnet" "example" without count, you might have aws_subnet.example already bound to a remote object in your state. If you add count = 1 to that resource then Terraform would previously silently rebind the object to aws_subnet.example[0] as part of planning, whereas now Terraform will mention that it did so explicitly in the plan description. (#29605)
    • terraform workspace delete: will now allow deleting a workspace whose state contains only data resource instances and output values, without running terraform destroy first. Previously the presence of data resources would require using -force to override the safety check guarding against accidentally forgetting about remote objects, but a data resource is not responsible for the management of its associated remote object(s) anyway. (#29754)
    • provisioner/remote-exec and provisioner/file: When using SSH agent authentication mode on Windows, Terraform can now detect and use the Windows 10 built-in OpenSSH Client's SSH Agent, when available, in addition to the existing support for the third-party solution Pageant that was already supported. (#29747)

    BUG FIXES:

    • core: Fixed an issue where provider configuration input variables were not properly merging with values in configuration (#29000)
    • core: Reduce scope of dependencies that may defer reading of data sources when using depends_on or directly referencing managed resources (#29682)
    • cli: Blocks using SchemaConfigModeAttr in the provider SDK can now represented in the plan json output (#29522)
    • cli: Prevent applying a stale planfile when there was no previous state (#29755)
    Source code(tar.gz)
    Source code(zip)
  • v1.0.9(Oct 13, 2021)

    1.0.9 (October 13, 2021)

    BUG FIXES:

    • core: Fix panic when planning new resources with nested object attributes (#29701)
    • core: Do not refresh deposed instances when the provider is not configured during destroy (#29720)
    • core: Prevent panic when encountering a missing change when destroying a resource (#29734)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.0-alpha20211006(Oct 6, 2021)

    1.1.0 (Unreleased)

    UPGRADE NOTES:

    • Terraform on macOS now requires macOS 10.13 High Sierra or later; Older macOS versions are no longer supported.

    • The terraform graph command no longer supports -type=validate and -type=eval options. The validate graph is always the same as the plan graph anyway, and the "eval" graph was just an implementation detail of the terraform console command. The default behavior of creating a plan graph should be a reasonable replacement for both of the removed graph modes. (Please note that terraform graph is not covered by the Terraform v1.0 compatibility promises, because its behavior inherently exposes Terraform Core implementation details, so we recommend it only for interactive debugging tasks and not for use in automation.)

    • terraform apply with a previously-saved plan file will now verify that the provider plugin packages used to create the plan fully match the ones used during apply, using the same checksum scheme that Terraform normally uses for the dependency lock file. Previously Terraform was checking consistency of plugins from a plan file using a legacy mechanism which covered only the main plugin executable, not any other files that might be distributed alongside in the plugin package.

      This additional check should not affect typical plugins that conform to the expectation that a plugin package's contents are immutable once released, but may affect a hypothetical in-house plugin that intentionally modifies extra files in its package directory somehow between plan and apply. If you have such a plugin, you'll need to change its approach to store those files in some other location separate from the package directory. This is a minor compatibility break motivated by increasing the assurance that plugins have not been inadvertently or maliciously modified between plan and apply.

    NEW FEATURES:

    • terraform plan and terraform apply: When Terraform plans to destroy a resource instance due to it no longer being declared in the configuration, the proposed plan output will now include a note hinting at what situation prompted that proposal, so you can more easily see what configuration change might avoid the object being destroyed. (#29637)
    • terraform plan and terraform apply: When Terraform automatically moves a singleton resource instance to index zero or vice-versa in response to adding or removing count, it'll report explicitly that it did so as part of the plan output. (#29605)
    • terraform add: The (currently-experimental) terraform add generates a starting point for a particular resource configuration. (#28874)
    • config: a new type() function, available only in terraform console. (#28501)

    ENHANCEMENTS:

    • config: Terraform now checks the syntax of and normalizes module source addresses (the source argument in module blocks) during configuration decoding rather than only at module installation time. This is largely just an internal refactoring, but a visible benefit of this change is that the terraform init messages about module downloading will now show the canonical module package address Terraform is downloading from, after interpreting the special shorthands for common cases like GitHub URLs. (#28854)
    • cli: Terraform will now report explicitly in the UI if it automatically moves a resource instance to a new address as a result of adding or removing the count argument from an existing resource. For example, if you previously had resource "aws_subnet" "example" without count, you might have aws_subnet.example already bound to a remote object in your state. If you add count = 1 to that resource then Terraform would previously silently rebind the object to aws_subnet.example[0] as part of planning, whereas now Terraform will mention that it did so explicitly in the plan description. (#29605)

    BUG FIXES:

    • core: Fixed an issue where provider configuration input variables were not properly merging with values in configuration (#29000)
    • cli: Blocks using SchemaConfigModeAttr in the provider SDK can now represented in the plan json output (#29522)
    Source code(tar.gz)
    Source code(zip)
  • v1.0.8(Sep 29, 2021)

    1.0.8 (September 29, 2021)

    BUG FIXES:

    • cli: Check required_version as early as possibly during init so that version incompatibility can be reported before errors about new syntax (#29665)
    • core: Don't plan to remove orphaned resource instances in refresh-only plans (#29640)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.0-alpha20210922(Sep 22, 2021)

    1.1.0 (Unreleased)

    UPGRADE NOTES:

    • Terraform on macOS now requires macOS 10.13 High Sierra or later; Older macOS versions are no longer supported.
    • The terraform graph command no longer supports -type=validate and -type=eval options. The validate graph is always the same as the plan graph anyway, and the "eval" graph was just an implementation detail of the terraform console command. The default behavior of creating a plan graph should be a reasonable replacement for both of the removed graph modes. (Please note that terraform graph is not covered by the Terraform v1.0 compatibility promises, because its behavior inherently exposes Terraform Core implementation details, so we recommend it only for interactive debugging tasks and not for use in automation.)

    NEW FEATURES:

    • cli: The (currently-experimental) terraform add generates a starting point for a particular resource configuration. (#28874)
    • config: a new type() function, only available in terraform console (#28501)

    ENHANCEMENTS:

    • config: Terraform now checks the syntax of and normalizes module source addresses (the source argument in module blocks) during configuration decoding rather than only at module installation time. This is largely just an internal refactoring, but a visible benefit of this change is that the terraform init messages about module downloading will now show the canonical module package address Terraform is downloading from, after interpreting the special shorthands for common cases like GitHub URLs. (#28854)
    • cli: Terraform will now report explicitly in the UI if it automatically moves a resource instance to a new address as a result of adding or removing the count argument from an existing resource. For example, if you previously had resource "aws_subnet" "example" without count, you might have aws_subnet.example already bound to a remote object in your state. If you add count = 1 to that resource then Terraform would previously silently rebind the object to aws_subnet.example[0] as part of planning, whereas now Terraform will mention that it did so explicitly in the plan description. (#29605)

    BUG FIXES:

    • core: Fixed an issue where provider configuration input variables were not properly merging with values in configuration (#29000)
    • cli: Blocks using SchemaConfigModeAttr in the provider SDK can now represented in the plan json output (#29522)
    Source code(tar.gz)
    Source code(zip)
  • v1.0.7(Sep 15, 2021)

    1.0.7 (September 15, 2021)

    BUG FIXES:

    • core: Remove check for computed attributes which is no longer valid with optional structural attributes (#29563)
    • core: Prevent object types with optional attributes from being instantiated as concrete values, which can lead to failures in type comparison (#29559)
    • core: Empty containers in the configuration were not planned correctly when used with optional structural attributes (#29580)
    Source code(tar.gz)
    Source code(zip)
  • v1.1.0-alpha20210908(Sep 8, 2021)

    1.1.0 (Unreleased)

    UPGRADE NOTES:

    • Terraform on macOS now requires macOS 10.13 High Sierra or later; Older macOS versions are no longer supported.
    • The terraform graph command no longer supports -type=validate and -type=eval options. The validate graph is always the same as the plan graph anyway, and the "eval" graph was just an implementation detail of the terraform console command. The default behavior of creating a plan graph should be a reasonable replacement for both of the removed graph modes. (Please note that terraform graph is not covered by the Terraform v1.0 compatibility promises, because its behavior inherently exposes Terraform Core implementation details, so we recommend it only for interactive debugging tasks and not for use in automation.)

    NEW FEATURES:

    • cli: The (currently-experimental) terraform add generates a starting point for a particular resource configuration. (#28874)
    • config: a new type() function, only available in terraform console (#28501)

    ENHANCEMENTS:

    • config: Terraform now checks the syntax of and normalizes module source addresses (the source argument in module blocks) during configuration decoding rather than only at module installation time. This is largely just an internal refactoring, but a visible benefit of this change is that the terraform init messages about module downloading will now show the canonical module package address Terraform is downloading from, after interpreting the special shorthands for common cases like GitHub URLs. (#28854)

    BUG FIXES:

    • core: Fixed an issue where provider configuration input variables were not properly merging with values in configuration (#29000)
    • cli: Blocks using SchemaConfigModeAttr in the provider SDK can now represented in the plan json output (#29522)
    Source code(tar.gz)
    Source code(zip)
  • v1.0.6(Sep 3, 2021)

    1.0.6 (September 03, 2021)

    ENHANCEMENTS:

    • backend/s3: Improve SSO handling and add new endpoints in the AWS SDK (#29017)

    BUG FIXES:

    • cli: Suppress confirmation prompt when initializing with the -force-copy flag and migrating state between multiple workspaces. (#29438)
    • cli: Update tencentcount dependency versions to fix errors when building from source (#29445)
    • core: Fix panic while handling computed attributes within nested objects, and improve plan validation for unknown values (#29482)
    Source code(tar.gz)
    Source code(zip)
  • v1.0.5(Aug 18, 2021)

    1.0.5 (August 18, 2021)

    BUG FIXES:

    • json-output: Add an output change summary message as part of the terraform plan -json structured logs, bringing this format into parity with the human-readable UI. (#29312)
    • core: Handle null nested single attribute values (#29411)
    • cli: Fix crash when planning a diff between null and empty sets in nested attributes (#29398)
    • cli: Fix crash when planning a new resource containing a set of nested object attributes (#29398)
    • cli: Fix crash when displaying a resource diff where a possibly identifying attribute is sensitive (#29397)
    • cli: Fix crash when a diff with unknown nested map attributes (#29410)
    • config: Fix handling of dynamically types arguments in formatlist, ensuring the correct resulting type. (#29408)
    • config: Floating point operations like floor and ceil can no longer mutate their arguments. (#29408)
    Source code(tar.gz)
    Source code(zip)
Owner
HashiCorp
Consistent workflows to provision, secure, connect, and run any infrastructure for any application.
HashiCorp
Terraform-equinix-migration-tool - Tool to migrate code from Equinix Metal terraform provider to Equinix terraform provider

Equinix Terraform Provider Migration Tool This tool targets a terraform working

Equinix 1 Feb 15, 2022
Continuous Delivery for Declarative Kubernetes, Serverless and Infrastructure Applications

Continuous Delivery for Declarative Kubernetes, Serverless and Infrastructure Applications Explore PipeCD docs » Overview PipeCD provides a unified co

PipeCD 582 May 12, 2022
sail is an operation framework based on Ansible/Helm. sail follows the principles of Infrastructure as Code (IaC), Operation as Code (OaC), and Everything as Code. So it is a tool for DevOps.

sail 中文文档 sail is an operation framework based on Ansible/Helm. sail follows the principles of Infrastructure as Code (IaC), Operation as Code (OaC),a

Bougou Nisou 10 Dec 16, 2021
ip-masq-agent-v2 aims to solve more specific networking cases, allow for more configuration options, and improve observability compared to the original.

ip-masq-agent-v2 Based on the original ip-masq-agent, v2 aims to solve more specific networking cases, allow for more configuration options, and impro

Microsoft Azure 2 May 6, 2022
kube-champ 33 Apr 21, 2022
LazyXds enables Istio only push needed xDS to sidecars to reduce resource consumption and speed up xDS configuration propagation.

LazyXds LazyXds enables Istio only push needed xDS to sidecars to reduce resource consumption and speed up xDS configuration propagation. Problems to

Aeraki Mesh 6 May 13, 2022
An open-source, distributed, cloud-native CD (Continuous Delivery) product designed for developersAn open-source, distributed, cloud-native CD (Continuous Delivery) product designed for developers

Developer-oriented Continuous Delivery Product ⁣ English | 简体中文 Table of Contents Zadig Table of Contents What is Zadig Quick start How to use? How to

null 0 Oct 19, 2021
A Kubernetes Operator, that helps DevOps team accelerate their journey into the cloud and K8s.

A Kubernetes Operator, that helps DevOps team accelerate their journey into the cloud and K8s. OAM operator scaffolds all of the code required to create resources across various cloud provides, which includes both K8s and Non-K8s resources

Pavan Kumar 2 Nov 30, 2021
Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration, and automating updates to configuration when there is new code to deploy.

Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories), and automating updates to configuration when there is new code to deploy.

Flux project 3.3k May 18, 2022
Vilicus is an open source tool that orchestrates security scans of container images(docker/oci) and centralizes all results into a database for further analysis and metrics.

Vilicus Table of Contents Overview How does it work? Architecture Development Run deployment manually Usage Example of analysis Overview Vilicus is an

Ederson Brilhante 76 Mar 22, 2022
The server-side reproduction, similar the one of https://popcat.click, improve the performance and speed.

PopCat Echo The server-side reproduction, similar the one of https://popcat.click, improve the performance and speed. Docker Image The docker image is

SuperSonic 61 Apr 19, 2022
An open source alternative to terraform enterprise.

oTF An open source alternative to terraform enterprise. Functionality is currently limited: Remote execution mode (plans and applies run remotely) Sta

Louis Garman 74 May 6, 2022
Shared counter (with max limit) for k6 load testing tool

xk6-increment This is a k6 extension using the xk6 system. ❗ This is a proof of concept, isn't supported by the k6 team, and may break in the future.

Michail Safronov 0 Nov 30, 2021
Cloud Infrastructure as Code

CloudIaC Cloud Infrastructure as Code CloudIaC 是基于基础设施即代码构建的云环境自动化管理平台。 CloudIaC 将易于使用的界面与强大的治理工具相结合,让您和您团队的成员可以快速轻松的在云中部署和管理环境。 通过将 CloudIaC 集成到您的流程中

iDCOS 78 May 11, 2022
Infrastructure as Code Workshop

infrastructure-as-code-workshop Infrastructure as Code Workshop Run Pulumi projects Just cd into the pulumi-* folder and type pulumi up Run Terraform

Engin Diri 3 Apr 26, 2022
go-opa-validate is an open-source lib that evaluates OPA (open policy agent) policy against JSON or YAML data.

go-opa-validate go-opa-validate is an open-source lib that evaluates OPA (open policy agent) policy against JSON or YAML data. Installation Usage Cont

chenk 5 Feb 5, 2022
Library/tool to change a yaml given a rules file

golang-yaml-rules/yaml-transform Library/tool to change a yaml given a rules file Using jsonpath ( https://github.com/vmware-labs/yaml-jsonpath ), thi

null 0 Feb 11, 2022
Bubbly is an open-source platform that gives you confidence in your continuous release process.

Bubbly Bubbly - Release Readiness in a Bubble Bubbly emerged from a need that many lean software teams practicing Continuous Integration and Delivery

Valocode 32 Apr 22, 2022