profile
viewpoint
Alisdair McDiarmid alisdair @hashicorp Toronto, Ontario https://alisdair.mcdiarmid.org/

a-song-a-day/a-song-a-day 4

For those "too busy" to discover new music.

alisdair/doofer 3

Sinatra, Haml, Sass, jQuery, Pow. A template for quick prototyping.

alisdair/brassica 2

A ridiculously over-engineered weblog (note: does not work yet)

alisdair/conditions 1

Simple web application to allow reporting of course conditions at my golf club.

alisdair/asana 0

Asana API client in Go

PR opened hashicorp/terraform

command: Providers schema shows required_providers

The providers schema command is using the Config.ProviderTypes method, which had not been kept up to date with the changes to provider requirements detection made in Config.ProviderRequirements. This resulted in any currently-unused providers being omitted from the output.

This commit changes the ProviderTypes method to use the same underlying logic as ProviderRequirements, which ensures that required_providers blocks are taken into account.

Includes an integration test case to verify that this fixes the provider schemas command bug.

Fixes #26306. Diff best viewed ignoring whitespace, due to the new nil check if statement.

+89 -55

0 comment

5 changed files

pr created time in 14 hours

issue commenthashicorp/terraform

Terraform 0.13 complains that all list elements must have the same type, while 0.12 does not.

Yes, there's documentation on structural types on this page. The example for defining a full object type isn't very prominent, though, so perhaps we could improve that.

marcosdiez

comment created time in 14 hours

create barnchhashicorp/terraform

branch : alisdair/providers-schema-required-providers

created branch time in 14 hours

issue commenthashicorp/terraform

Terraform 0.13 complains that all list elements must have the same type, while 0.12 does not.

While investigating this a bit further, I found a workaround that might be useful to you. If you specify the full type of the input variable to m2, Terraform's type checking works correctly:

variable "target_subnets" {
  type    = list(object({
    name = string
    value = object({
      cidr_block = string
      tg_attachment_id = string
    })
  }))
  default = []
}

output "target_subnets" {
    value = var.target_subnets
}

Hopefully this applies to your real configuration, too!

I currently still think this is a bug, and I'm going to keep looking into it for now.

marcosdiez

comment created time in 14 hours

issue commenthashicorp/terraform

Terraform 0.13 complains that all list elements must have the same type, while 0.12 does not.

An initial debugging session indicates that Terraform is trying to convert the target_subnets argument to m2 from a tuple to a list, and the tuple element types are dynamic and the expected object({…}) type. The output from module m1 is an unknown value of dynamic type at the time this is happening, which is surprising.

marcosdiez

comment created time in 14 hours

issue commenthashicorp/terraform

Terraform 0.13 complains that all list elements must have the same type, while 0.12 does not.

Thank you, this is super helpful! I'm able to reproduce with these steps, and also confirm that the issue is present in Terraform 0.14.0-dev.

marcosdiez

comment created time in 15 hours

create barnchhashicorp/terraform

branch : pselle/sensitive-values-path-serialization

created branch time in 15 hours

issue closedhashicorp/terraform

Can't remove bad providers from local install

Terraform Version

Terraform v0.13.2

Terraform Configuration Files

So I did something silly, and I can't figure out how to undo it. I made a guess that there was a Terraform provider for IBM Cloud, and I set up a configuration as follows:

terraform {
  required_providers {
    ibm = {
      source  = "hashicorp/ibm"
    }
  }
}

Of course, that doesn't exist, and I got a nasty error. Fair enough. I went back and read the documentation.

I then downloaded the correct community provider and placed it in the ~/.terraform.d/plugins directory. However, whenever I try to run terraform init, it continues to refer back to the registry.terraform.io/hashicorp/ibm provider.

I've removed all references to hashicorp/ibm, but terraform still seems determined to equate any provider name of ibm to be hashicorp/ibm. How do I get rid of this association?

My current provider.tf file:

provider "ibm" {
  ibmcloud_api_key   = var.ibmcloud_api_key
  generation         = 1
  region             = "us-south"
  iaas_classic_username = var.iaas_classic_username
  iaas_classic_api_key  = var.iaas_classic_api_key
}

Debug Output

<!-- Full debug output can be obtained by running Terraform with the environment variable TF_LOG=trace. Please create a GitHub Gist containing the debug output. Please do not paste the debug output in the issue, since debug output is long.

Debug output may contain sensitive information. Please review it before posting publicly, and if you are concerned feel free to encrypt the files using the HashiCorp security public key. -->

> terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of hashicorp/ibm...

Error: Failed to install provider

Error while installing hashicorp/ibm: provider registry registry.terraform.io
does not have a provider named registry.terraform.io/hashicorp/ibm

Expected Behavior

<!-- What should have happened? --> I have tried several approaches to reset this:

  • delete the directory that contains the terraform scripts
  • completely remove the ~/.terraform.d directory
  • re-install the plugin
  • run every known permutation of terraform providers

Nothing seems to get rid of the quest for hashicorp/ibm. Is there some secret config file that I need to update to remove this?

Actual Behavior

<!-- What actually happened? --> It keeps looking for the wrong provider.

closed time in 15 hours

tcrowleyibm

pull request commenthashicorp/terraform

Fixed nested list conversion in setElementCompare

@frostoov Thanks for submitting this pull request!

I can't quite follow the context in which you made this change. Do you have a relevant bug report that you can link to? I'm wondering what the consequence of this is in real-world Terraform usage.

frostoov

comment created time in 15 hours

issue commenthashicorp/terraform

Can't create azurerm_cognitive_account kind AnomalyDetector

@dgonzalezp That's confusing! With your exact configuration, Terraform initializes correctly for me:

$ cat main.tf
terraform {
  required_version = ">= 0.13"
  required_providers {
    azurerm = {
      source = "hashicorp/azurerm"
      version = "2.27.0"
    }
  }
}
$ terraform-0.13.3 init

Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/azurerm versions matching "2.27.0"...
- Installing hashicorp/azurerm v2.27.0...
- Installed hashicorp/azurerm v2.27.0 (signed by HashiCorp)

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Do you have any configuration in your ~/.terraformrc or similar which might be affecting the registry? For example, explicit provider installation configuration blocks.

dgonzalezp

comment created time in 19 hours

issue commenthashicorp/terraform

Missing provider error when using alias

Hi @Dissonant-Tech. It looks like you might have some instances of Datadog resources in an 0.12 format state file, which are causing the provider to be associated to hashicorp/datadog.

Can you show the output of terraform providers?

For more on this, please see the 0.13 upgrade guide FAQ, which explains how to use terraform state replace-provider to fix the problem.

Dissonant-Tech

comment created time in 20 hours

issue commenthashicorp/terraform

[0.13.1] Terraform displaying sensitive values in the logs

I believe that should be sufficient. I just upgraded to 3.7.0 and the issue is fixed for me:

$ terraform-0.13.3 plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.aws_kms_secrets.example: Refreshing state...
aws_kms_key.a: Refreshing state... [id=4f9c0013-e120-4161-8c6f-3be78328d1df]

------------------------------------------------------------------------

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
 <= read (data resources)

Terraform will perform the following actions:

  # data.aws_kms_secrets.example will be read during apply
  # (config refers to values not yet known)
 <= data "aws_kms_secrets" "example"  {
      ~ id        = "2020-09-21 13:18:38.655549 +0000 UTC" -> "2020-09-21 13:18:40.086338 +0000 UTC"
        plaintext = (sensitive value)

        secret {
            context      = {}
            grant_tokens = []
            name         = "password"
            payload      = <<~EOT
                AQICAHh8v6S5v9NE0eczrkCl/eYGAxvwnhN9TTCm6U97KGT47AEoY72NqYm7epCh4IckEJs5AAAAZTBjBgkqhkiG9w0BBwagVjBUAgEAME8GCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMxYffoUGQjpOafAlQAgEQgCLkZURWEo2Gi1jU68iRhrhDfGQztnfUMYS1JTjWh2CXDUD1
            EOT
        }
    }
zopanix

comment created time in 21 hours

issue commenthashicorp/terraform

[0.13.1] Terraform displaying sensitive values in the logs

@nbari Please upgrade your AWS provider version to incorporate the bug fix.

zopanix

comment created time in 21 hours

Pull request review commenthashicorp/terraform

Mildwonkey/type func

 func FormatValue(v cty.Value, indent int) string { 	case ty.IsPrimitiveType(): 		switch ty { 		case cty.String:-			// FIXME: If it's a multi-line string, better to render it using-			// HEREDOC-style syntax.+			// If this is a multi-line string, return it as-is+			if strings.Contains(v.AsString(), "\n") {+				return v.AsString()+			}

I'm not so sure about this. The goal of the using this formatter was to produce results which would round-trip to the same values. Treating multi-line strings like this just to suit the type function breaks this.

I do really like the multi-line output for the type result being a unformatted literal type. Could we achieve that some other way? Perhaps using marks, or a capsule type?

mildwonkey

comment created time in 4 days

Pull request review commenthashicorp/terraform

Mildwonkey/type func

 func (c *ConsoleCommand) Run(args []string) int { 		c.showDiagnostics(diags) 		return 1 	}+	scope.AddFunc("type", funcs.TypeFunc)

🔍 Neat!

mildwonkey

comment created time in 4 days

Pull request review commenthashicorp/terraform

Mildwonkey/type func

 func MakeToFunc(wantTy cty.Type) function.Function { 		}, 	}) }++var TypeFunc = function.New(&function.Spec{+	Params: []function.Parameter{+		{+			Name:             "value",+			Type:             cty.DynamicPseudoType,+			AllowDynamicType: true,+			AllowUnknown:     true,+			AllowNull:        true,+		},+	},+	Type: function.StaticReturnType(cty.String),+	Impl: func(args []cty.Value, retType cty.Type) (cty.Value, error) {+		return cty.StringVal(TypeString(args[0].Type())), nil+	},+})++// Modified copy of TypeString from go-cty:+// https://github.com/zclconf/go-cty-debug/blob/master/ctydebug/type_string.go+//+// TypeString returns a string representation of a given type that is+// reminiscent of Go syntax calling into the cty package but is mainly+// intended for easy human inspection of values in tests, debug output, etc.+//+// The resulting string will include newlines and indentation in order to+// increase the readability of complex structures. It always ends with a+// newline, so you can print this result directly to your output.+func TypeString(ty cty.Type) string {+	var b strings.Builder+	writeType(ty, &b, 0)+	b.WriteByte('\n') // always end with a newline for easier printing+	return b.String()+}++func writeType(ty cty.Type, b *strings.Builder, indent int) {+	switch {+	case ty == cty.NilType:+		b.WriteString("nil")+		return+	case ty.IsObjectType():+		atys := ty.AttributeTypes()+		if len(atys) == 0 {+			b.WriteString("object{}")+			return+		}+		attrNames := make([]string, 0, len(atys))+		for name := range atys {+			attrNames = append(attrNames, name)+		}+		sort.Strings(attrNames)+		b.WriteString("object(map[string]{\n")

Displaying the object type seems like one of the most valuable parts of this idea. I think it would be clearer to do so using the same HCL-based format that we use for type constraints, rather than referring to Go-like syntax. For example:

object({
  a = string,
  b = object({
    c = bool
  })
})

What do you think?

mildwonkey

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commenthashicorp/terraform

lang/funcs: add "all" function

 func TestLength(t *testing.T) { 	} } +func TestAll(t *testing.T) {+	tests := []struct {+		Collection cty.Value+		Want       cty.Value+		Err        bool+	}{+		{+			cty.ListValEmpty(cty.String),+			cty.True,+			false,+		},+		{+			cty.TupleVal([]cty.Value{}),+			cty.True,+			false,+		},+		{+			cty.SetValEmpty(cty.Bool),+			cty.True,+			false,+		},+		{+			cty.ListVal([]cty.Value{cty.True}),+			cty.True,+			false,+		},+		{+			cty.ListVal([]cty.Value{cty.StringVal("true")}),+			cty.True,+			false,+		},+		{+			cty.ListVal([]cty.Value{cty.False}),+			cty.False,+			false,+		},+		{+			cty.ListVal([]cty.Value{cty.True, cty.False}),+			cty.False,+			false,+		},+		{+			cty.ListVal([]cty.Value{cty.False, cty.True}),+			cty.False,+			false,+		},+		{+			cty.ListVal([]cty.Value{cty.NumberIntVal(1)}),+			cty.False,+			false,+		},+		{+			cty.StringVal("true"),+			cty.False,+			true,+		},+		// {+		// 	cty.ListVal([]cty.Value{cty.ListValEmpty(cty.String)}),+		// 	cty.False,+		// 	false,+		// },+		// {+		// 	cty.ListVal([]cty.Value{cty.True, cty.StringVal("true")}),+		// 	cty.True,+		// 	false,+		// },+		// {+		// 	cty.ListVal([]cty.Value{cty.UnknownVal(cty.String)}),+		// 	cty.False,+		// 	false,+		// },

Ah, that failure makes sense—you can't attempt to convert an unknown value to bool.

Generally we want to propagate unknownness. If the list contains unknown values, then it is unknown if all of them are true—so we defer that decision until they become known by returning an unknown value of the correct type. In this case, that means that the return value should be cty.UnknownVal(cty.Bool) with no error, not cty.False.

You can use v.IsKnown() to determine the unknownness of each element value.

artburkart

comment created time in 4 days

PullRequestReviewEvent

issue commenthashicorp/terraform

'terraform init' errors with "Blocks of type "terraform" are not expected here." When utilizing backend.tf file. Worked in 12.29

The Documentation that led me to using this was found here

Thanks! We recently updated those docs, and you might not have noticed this new section on backend configuration override files:

A backend configuration file has the contents of the backend block as top-level attributes, without the need to wrap it in another terraform or backend block:

address = "demo.consul.io"
path    = "example_app/terraform_state"
scheme  = "https"

On your follow-up:

Tried this and I got an error for each key.

Ah, I see what's going on. This is caused by having your backend configuration override file named backend.tf—or alternatively, attempting to use the Terraform file containing your backend configuration as an override file.

Your original backend.tf file is completely valid Terraform configuration, and if that's the only definition for your backend, the original code was correct. However, in that case, your original command is incorrect—you need to remove the -backend-config="backend.tf" argument.

The reason you saw this working in Terraform 0.12.29 is because Terraform ignored that argument. You don't need to provide it unless you want to override the backend configuration in your main .tf files.

So, in summary, I think you want to:

  • Undo the changes you just made to backend.tf (sorry! 😅)
  • Remove the -backend-config="backend.tf" argument from your init command

Hope that works!

CroweDadams

comment created time in 4 days

PullRequestReviewEvent

issue commenthashicorp/terraform

Crash when using depends_on with data source

Same stack trace as #25463, so probably related.

alisdair

comment created time in 4 days

issue closedhashicorp/terraform

'terraform init' errors with "Blocks of type "terraform" are not expected here." When utilizing backend.tf file. Worked in 12.29

<!-- Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

If your issue relates to a specific Terraform provider, please open it in the provider's own repository. The index of providers is at https://github.com/terraform-providers . -->

Terraform Version

<!--- Run terraform version to show the version, and paste the result between the ``` marks below.

If you are not running the latest version of Terraform, please try upgrading because your issue may have already been fixed. -->

Terraform v0.13.3 on Linux (also verified on MacOS command line)

Terraform Configuration Files

<!-- Paste the relevant parts of your Terraform configuration between the ``` marks below.

For large Terraform configs, please use a service like Dropbox and share a link to the ZIP file. For security, you can also encrypt the files using our GPG public key. -->

Standard configuration

Debug Output

<!-- Full debug output can be obtained by running Terraform with the environment variable TF_LOG=trace. Please create a GitHub Gist containing the debug output. Please do not paste the debug output in the issue, since debug output is long.

Debug output may contain sensitive information. Please review it before posting publicly, and if you are concerned feel free to encrypt the files using the HashiCorp security public key. -->

Crash Output

<!-- If the console output indicates that Terraform crashed, please share a link to a GitHub Gist containing the output of the crash.log file. -->

Expected Behavior

terraform should init and accept the backend.tf

Actual Behavior

Terraform errors out with the following text.

Initializing the backend...

Error: Unsupported block type

on backend.tf line 1: 1: terraform {

Blocks of type "terraform" are not expected here.

Steps to Reproduce

Please list the full steps required to reproduce the issue, for example:

  1. create a backend.tf
  2. terraform init -backend-config="backend.tf" -backend-config="key=[[some_key]].tfstate" -input=false -reconfigure

Additional Context

backend.tf contents

terraform {
  backend "azurerm" {
    resource_group_name  = "[[resource_group_name"
    storage_account_name = "[[storage_account_name]]"
    container_name       = "[[somecontainer]]"
    access_key		 = "[[removed]]"
    key			 = "[[some-key]]"
  }
}

References

<!-- Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

  • #6017

-->

closed time in 4 days

CroweDadams

issue commenthashicorp/terraform

'terraform init' errors with "Blocks of type "terraform" are not expected here." When utilizing backend.tf file. Worked in 12.29

Hi @CroweDadams, thanks for reporting this.

The backend configuration file should not contain a terraform block. Instead, it should contain the contents of your backend block. Like this:

resource_group_name  = "[[resource_group_name]]"
storage_account_name = "[[storage_account_name]]"
container_name       = "[[somecontainer]]"
access_key           = "[[removed]]"
key                  = "[[some-key]]"

Hope this helps! I'm going to close this issue as Terraform is working as designed here. However, if you could let us know of any documentation which led you to put the entire terraform block in this file, that would be appreciated!

CroweDadams

comment created time in 4 days

issue closedhashicorp/terraform

Update dependency before destroy

Terraform Version

Terraform v0.12.24

Terraform Configuration Files

I created https://github.com/terraform-providers/terraform-provider-google/issues/6376 in the Google provider, but I was told this is a TF issue. I'm also not sure if this issue is the same issue as https://github.com/hashicorp/terraform/issues/8099, so I created a new one.

In the config below the problem is when you want to lower the number of google_compute_instance_group that are used in a google_compute_region_backend_service it's not possible because you cannot delete an instance group that is being used in a backend service.

Here is an example config:

locals {
  project         = "<project-id>"
  network         = "<vpc-name>"
  network_project = "<vpc-project>"
  zones           = ["europe-west1-b", "europe-west1-c", "europe-west1-d"]
  s1_count        = 3
}

provider "google" {
  project = local.project
  version = "~> 3.0"
}

data "google_compute_network" "network" {
  name    = local.network
  project = local.network_project
}

resource "google_compute_region_backend_service" "s1" {
  name = "s1"

  dynamic "backend" {
    for_each = google_compute_instance_group.s1
    content {
      group = backend.value.self_link
    }
  }
  health_checks = [
    google_compute_health_check.default.self_link,
  ]
}

resource "google_compute_health_check" "default" {
  name = "s1"
  tcp_health_check {
    port = "80"
  }
}

resource "google_compute_instance_group" "s1" {
  count   = local.s1_count
  name    = format("s1-%02d", count.index + 1)
  zone    = element(local.zones, count.index)
  network = data.google_compute_network.network.self_link
}

Expected Behavior

When I lower the number of instance groups (e.g. set s1_count = 2 in the example above) TF should:

  1. Update google_compute_region_backend_service (remove the last instance group from it)
  2. Delete the surplus google_compute_instance_group

Actual Behavior

  1. Delete the surplus google_compute_instance_group -> fails
  2. Update google_compute_region_backend_service (remove the last instance group from it)

Here is the output:

google_compute_instance_group.s1[2]: Destroying... [id=projects/<project-id>/zones/europe-west1-d/instanceGroups/s1-03]

Error: Error deleting InstanceGroup: googleapi: Error 400: The instance_group resource 'projects/<project-id>/zones/europe-west1-d/instanceGroups/s1-03' is already being used by 'projects/<project-id>/regions/europe-west1/backendServices/s1', resourceInUseByAnotherResource

Steps to Reproduce

Set s1_count to the lower number than before and run terraform apply.

Additional Context

Very big problem with all this is that it's not easy to fix because it requires some config hacks, running apply multiple times doesn't help.

References

  • https://github.com/terraform-providers/terraform-provider-google/issues/6376
  • https://github.com/hashicorp/terraform/issues/8099

closed time in 4 days

kustodian

issue commenthashicorp/terraform

Update dependency before destroy

This has now been reopened upstream, and I therefore believe it is a provider bug, so I'm going to mark the core issue closed. If you believe that is a mistake, please let me know!

kustodian

comment created time in 4 days

issue closedhashicorp/terraform

0.13.x: Destroying resource with -target doesn't destroy resources defined in data blocks in module that depends on targeted resource

Terraform Version

Terraform v0.13.2
+ provider registry.terraform.io/hashicorp/azurerm v2.25.0

Terraform Configuration Files

### main.tf
provider "azurerm" {
  version = "~> 2.25.0"
  features {}
}

resource "azurerm_resource_group" "outer_rg" {
  name     = "outer_rg"
  location = "eastus"
}

module "testmodule" {
  source = "./testmodule"
  rg_name = azurerm_resource_group.outer_rg.name
  depends_on = [azurerm_resource_group.outer_rg]
}

### testmodule/main.tf
variable "rg_name" {
  description = "Resource group name"
}

data "azurerm_resource_group" "data_rg" {
  name = var.rg_name
}

resource "azurerm_resource_group" "inner_rg" {
  name = "inner_rg"
  location = "eastus"
}

Expected Behavior

terraform apply
terraform destroy -target=azurerm_resource_group.outer_rg
terraform state list
# Expecting no output here

Actual Behavior

$ terraform state list
module.testmodule.data.azurerm_resource_group.data_rg

Steps to Reproduce

terraform init
terraform apply
terraform destroy -target=azurerm_resource_group.outer_rg
terraform state list

Additional Context

Hello!

I am experimenting with using depends_on statements in modules in Terraform 0.13.x. One thing I noticed is that if a module's declaration depends on a resource and that resource is destroyed with terraform destroy -target=azurerm_resource_group.outer_rg (e.g.), any data blocks that are defined inside of the module will have resources left over when inspecting the output of terraform state list once the destroy is complete. Although this isn't necessarily the end of the world, it is kind of annoying: subsequent terraform applys will fail because it will try to refresh the module.testmodule.data.azurerm_resource_group.data_rg resource that is believed to still exist.

I'm not necessarily sure if this is a bug or not, but it does seem to possibly be slightly surprising - if I have a module and destroy the thing that module depends on, shouldn't everything inside the module be destroyed too? In my 'mental model' of modules, there isn't a real reason to keep that data resource around - it only exists inside of that module to look up some value for further resource declarations.

closed time in 4 days

9numbernine9

issue commenthashicorp/terraform

0.13.x: Destroying resource with -target doesn't destroy resources defined in data blocks in module that depends on targeted resource

We discussed this behaviour internally, and I wanted to share some of the outcomes.

Most importantly, targeted destroy does not affect data sources, even without the complication of a module or depends_on. Consider this configuration:

resource "null_resource" "a" {
}

data "null_data_source" "b" {
  inputs = { a: null_resource.a.id }
}
  • terraform init, terraform apply -auto-approve
  • terraform destroy -target null_resource.a does not destroy the data source

While it's a rough edge, this is considered reasonable behaviour for targeted destroy, which as I mentioned above is not recommended as part of a main workflow. It's definitely not ideal, but the concept of -target in general is one that we would eventually like to make obsolete.

We do not intend to change the behaviour of targeted destroy with regards to data sources, and instead will focus on the other improvements which should make it unnecessary. As a result, I'm going to close this issue as "working as designed", for want of a more useful thing to do.

Thanks again for reporting the issue, and I hope this explains what's happening under the hood!

9numbernine9

comment created time in 4 days

issue commenthashicorp/terraform

`terraform show`, `terraform state show ADDR`, and `terraform show -json` not showing all (or consistent) data

For the discrepancy between terraform show and terraform show -json with nested modules, see #25494.

lexrj

comment created time in 4 days

issue commenthashicorp/terraform

terraform show -json module map is empty

I believe the issue is in this loop: https://github.com/hashicorp/terraform/blob/6d7904c17b2a724a32fc8f8b1f66a0788376426e/command/jsonstate/state.go#L199-L208

For my simple repro case above, this results in a moduleMap containing one key ("module.a"), as the only module in state is module.a.module.b.

This results in an empty output, because the following line only considers modules starting from root:

https://github.com/hashicorp/terraform/blob/6d7904c17b2a724a32fc8f8b1f66a0788376426e/command/jsonstate/state.go#L210-L211

The solution to this will have to ensure that we can cope with intermediate modules which do not have any resources, but do have child modules. It's not immediately obvious to me how we fix this, but I think it will be isolated to marshalRootModule and marshalModules.

Workaround: for anyone else hitting this bug, adding a null_resource instance in any modules which exclusively call other modules will ensure that their descendants are rendered in terraform show -json

wils0ns

comment created time in 4 days

issue commenthashicorp/terraform

terraform show -json module map is empty

Here's a very simple reproduction:

main.tf

module "a" {
  source = "./a"
}

a/main.tf:

module "b" {
  source = "./b"
}

a/b/main.tf:

resource "null_resource" "none" {}

Reproduction:

  • terraform init
  • terraform apply -auto-approve
  • terraform show (shows the resource)
  • terraform show -json (shows an empty state)

Confirmed on Terraform 0.12.28 and 0.13.3.

wils0ns

comment created time in 4 days

issue closedhashicorp/terraform

Extra connection attributes for DMS S3 Endpoints incomplete --> no error is shown

<!-- Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

If your issue relates to a specific Terraform provider, please open it in the provider's own repository. The index of providers is at https://github.com/terraform-providers . -->

Terraform Version

<!--- Run terraform version to show the version, and paste the result between the ``` marks below.

If you are not running the latest version of Terraform, please try upgrading because your issue may have already been fixed. -->

Terraform v0.13.2

Terraform Configuration Files

<!-- Paste the relevant parts of your Terraform configuration between the ``` marks below.

For large Terraform configs, please use a service like Dropbox and share a link to the ZIP file. For security, you can also encrypt the files using our GPG public key. -->

resource "aws_dms_endpoint" "s3_endpoint" {

  count                       = length(var.zones)
  endpoint_id                 = "${var.s3_endpoint_id_prefix}-${var.environment}-${var.shortApp}-${var.zones[count.index]}"
  endpoint_type               = "target"
  engine_name                 = "s3"
  ssl_mode                    = "none"
  kms_key_arn = var.kms_key_arn
extra_connection_attributes = "ServiceAccessRoleArn=${var.service_access_role_arn};bucketFolder=${var.zones[count.index]}/dms-export/${var.shortApp};bucketName=${var.bucket_name};cannedAclForObjects=BUCKET_OWNER_FULL_CONTROL;cdcPath=undefined;compressionType=NONE;csvDelimiter=,;csvRowDelimiter=\n;dataFormat=csv;datePartitionEnabled=false;includeOpForFullLoad=true;timestampColumnName=CDCTIMESTAMP"
  
  
  s3_settings {
    bucket_folder           = "${var.zones[count.index]}/dms-export/${var.shortApp}"
    bucket_name             = var.bucket_name
    service_access_role_arn = var.service_access_role_arn

  }

  tags = merge(var.tags, { "global.project" = "${local.global_project_tag}" })

}
...

Debug Output

<!-- Full debug output can be obtained by running Terraform with the environment variable TF_LOG=trace. Please create a GitHub Gist containing the debug output. Please do not paste the debug output in the issue, since debug output is long.

Debug output may contain sensitive information. Please review it before posting publicly, and if you are concerned feel free to encrypt the files using the HashiCorp security public key. --> https://gist.github.com/Olgoetz/9e7aec3af0af47b347822f20d0ce6b47

Crash Output

<!-- If the console output indicates that Terraform crashed, please share a link to a GitHub Gist containing the output of the crash.log file. -->

Expected Behavior

<!-- What should have happened? --> The extra connection attributes should look like:

ServiceAccessRoleArn=arn:aws:iam::*******:role/SDP_DMS_MIGRATION_TO_S3_ROLE;bucketFolder=komo/dms-export/pc;bucketName=*****-nonprod-sdp-lz-stag-pnc;cannedAclForObjects=BUCKET_OWNER_FULL_CONTROL;cdcPath=undefined;compressionType=NONE;csvDelimiter=,;csvRowDelimiter=\n;dataFormat=csv;datePartitionEnabled=false;includeOpForFullLoad=true;timestampColumnName=CDCTIMESTAMP

Actual Behavior

<!-- What actually happened? --> When I go to the endpoint in the AWS management console, these are the settings in extra connection attributes:

bucketFolder=komo/dms-export/pc;bucketName=axade-nonprod-sdp-lz-stag-pnc;compressionType=NONE;csvDelimiter=,;csvRowDelimiter=\n;datePartitionEnabled=false;

Steps to Reproduce

<!-- Please list the full steps required to reproduce the issue, for example:

  1. terraform init
  2. terraform apply -->
  3. terraform init
  4. terraform apply

Additional Context

<!-- Are there anything atypical about your situation that we should know? For example: is Terraform running in a wrapper script or in a CI system? Are you passing any unusual command line options or environment variables to opt-in to non-default behavior? -->

No.

References

<!-- Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

  • #6017

-->

closed time in 4 days

Olgoetz

issue commenthashicorp/terraform

Extra connection attributes for DMS S3 Endpoints incomplete --> no error is shown

Thanks for reporting this! I believe this is a bug in the AWS provider: https://github.com/terraform-providers/terraform-provider-aws/issues/8009. Closing this issue as it is not on Terraform core.

Olgoetz

comment created time in 4 days

issue closedhashicorp/terraform

Can't create azurerm_cognitive_account kind AnomalyDetector

Hello, I'm trying to created an azure cognitive resource of Kind AnomalyDetector. Its on the documentation list.

https://www.terraform.io/docs/providers/azurerm/r/cognitive_account.html

image

But when I try to create it, its failing.

Terraform Version

daniel@Mac02 allow_destroy % terraform version
Terraform v0.13.3
+ provider registry.terraform.io/hashicorp/azurerm v2.26.0

Terraform Configuration Files

resource "azurerm_resource_group" "rg_cognitive" {
  name     = "rg-cognitive"
  location = "uksouth"
}

resource "azurerm_cognitive_account" "anomaly_detector" {
  name                = "cog-anomaly-detector"
  location            = azurerm_resource_group.rg_cognitive.location
  resource_group_name = azurerm_resource_group.rg_cognitive.name

  kind                = "AnomalyDetector"
  sku_name            = "S0"
}

Debug Output

Error: expected kind to be one of [Academic Bing.Autosuggest Bing.Autosuggest.v7 Bing.CustomSearch Bing.Search Bing.Search.v7 Bing.Speech Bing.SpellCheck Bing.SpellCheck.v7 CognitiveServices ComputerVision ContentModerator CustomSpeech CustomVision.Prediction CustomVision.Training Emotion Face FormRecognizer ImmersiveReader LUIS LUIS.Authoring QnAMaker Recommendations SpeakerRecognition Speech SpeechServices SpeechTranslation TextAnalytics TextTranslation WebLM], got AnomalyDetector

  on res_cognitive.tf line 78, in resource "azurerm_cognitive_account" "anomaly_detector":
  78: resource "azurerm_cognitive_account" "anomaly_detector" {


Releasing state lock. This may take a few moments...

References

<!-- Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

  • #6017

-->

closed time in 4 days

dgonzalezp

issue commenthashicorp/terraform

Can't create azurerm_cognitive_account kind AnomalyDetector

Support for the AnomalyDetector was added in version 2.27 of the AzureRM provider, in this PR: https://github.com/terraform-providers/terraform-provider-azurerm/pull/8357

Please upgrade to 2.27.

dgonzalezp

comment created time in 4 days

issue commenthashicorp/terraform

module.cloud_router.google_compute_router_nat.nats["nat-dh329"] still contains unknown values during apply

Hi @SmartassSkeleton, thanks for reporting this. I'm unable to reproduce this bug without a more complete configuration. A simple invocation of the cloud-router module works fine for me with Terraform 0.12.29:

provider "google" {
  version = "~> 3.0"
}

module "cloud-router" {
  source  = "terraform-google-modules/cloud-router/google"
  version = "0.2.0"

  name    = "example-router"
  project = "terraform-core-alisdair"
  network = "default"
  region  = "us-central1"
}

Please provide a complete, runnable configuration which demonstrates the issue, so that we can determine the cause. This means either simplifying the configuration to remove references to other modules, or including the minimal source of those modules in your report. Thanks!

SmartassSkeleton

comment created time in 4 days

issue commenthashicorp/terraform

template_file data always read during plan/apply if resource inside module

Hi @kostiukolex, thanks for reporting this.

I'm not able to reproduce the issue you're seeing. Here's the configuration I'm using:

main.tf:

module "hello-alisdair" {
  source = "./hello"
  name   = "alisdair"
}

output "hello" {
  value = module.hello-alisdair.greeting
}

hello/main.tf:

variable "name" {
  type = string
}

data "template_file" "hello" {
  template = file("${path.module}/hello.tpl")
  vars = {
    name = var.name
  }
}

output "greeting" {
  value = data.template_file.hello.rendered
}

hello/hello.tpl:

Hello, ${name}!

Applying the configuration creates the correct output:

$ terraform-0.13.3 apply -auto-approve
module.hello-alisdair.data.template_file.hello: Refreshing state...

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

hello = Hello, alisdair!

Plan does not reread the template_file data:

$ terraform-0.13.3 plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

module.hello-alisdair.data.template_file.hello: Refreshing state... [id=d0c1be373e8b11ba8f69ded55954fcfba70daae3c8f59512267e590ca4d9b546]

------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.

Can you adjust this simple configuration to cause the problem to reappear, so that we can see what is causing the issue?

kostiukolex

comment created time in 4 days

issue openedhashicorp/terraform

Crash when using depends_on with data source

Terraform Version

Build from commit 6d7904c

Terraform v0.14.0-dev
+ provider registry.terraform.io/hashicorp/archive v1.3.0
+ provider registry.terraform.io/hashicorp/null v2.1.2

Terraform Configuration Files

resource "null_resource" "create_file" {
  provisioner "local-exec" {
    command = "mkdir -p files && echo foo > files/test.txt"
  }
}

data "archive_file" "foo" {
  depends_on = [null_resource.create_file]
  type        = "zip"
  source_dir  = "files"
  output_path = "files.zip"
}

Debug Output

Gist

Crash Output

Gist

Expected Behavior

I get a nice zip file

Actual Behavior

Crash:

panic: Failed to serialize resource instance in state: Instance data.archive_file.foo has status ObjectPlanned, which cannot be saved in state.

goroutine 8 [running]:
github.com/hashicorp/terraform/states/statefile.StatesMarshalEqual(0xc0000101b0, 0xc0000101a0, 0x0)
	/Users/alisdair/code/terraform/states/statefile/marshal_equal.go:31 +0x23b
github.com/hashicorp/terraform/states/statemgr.(*Filesystem).writeState(0xc000216600, 0xc000010170, 0x0, 0x0, 0x0)
	/Users/alisdair/code/terraform/states/statemgr/filesystem.go:201 +0x507
github.com/hashicorp/terraform/states/statemgr.(*Filesystem).WriteState(0xc000216600, 0xc000010170, 0x0, 0x0)
	/Users/alisdair/code/terraform/states/statemgr/filesystem.go:136 +0x7f
github.com/hashicorp/terraform/states/statemgr.WriteAndPersist(0xd4a8f90, 0xc000216600, 0xc000010170, 0xd4a8f90, 0xc000216600)
	/Users/alisdair/code/terraform/states/statemgr/helper.go:48 +0x3f
github.com/hashicorp/terraform/backend/local.(*Local).opApply(0xc000120f70, 0x38d6dc0, 0xc0002a7480, 0x38d6dc0, 0xc0002a74c0, 0xc0005b6460, 0xc0002a7440)
	/Users/alisdair/code/terraform/backend/local/backend_apply.go:171 +0x733
github.com/hashicorp/terraform/backend/local.(*Local).Operation.func1(0xc0006002f0, 0xc000600300, 0xc000600310, 0xc000120f70, 0xc0006002e0, 0x38d6dc0, 0xc0002a7480, 0x38d6dc0, 0xc0002a74c0, 0xc0005b6460, ...)
	/Users/alisdair/code/terraform/backend/local/backend.go:340 +0xe8
created by github.com/hashicorp/terraform/backend/local.(*Local).Operation
	/Users/alisdair/code/terraform/backend/local/backend.go:334 +0x366

Steps to Reproduce

  1. terraform init
  2. terraform apply -auto-approve

Additional Context

Hi @jbardin

References

Discovered when reproducing #26298. This configuration works with 0.13.3.

created time in 4 days

issue commenthashicorp/terraform

depends_on in data "resource" doesn't work anymore in terraform version 0.13

Thanks for reporting this, @NiklasKasper! I'm not able to reproduce this with a slightly simpler example:

resource "null_resource" "create_file" {
  triggers = {
    always_run = timestamp()
  }

  provisioner "local-exec" {
    command = "mkdir -p files && echo foo > files/test.txt"
  }
}

data "archive_file" "foo" {
  depends_on = [
    null_resource.create_file
  ]
  type        = "zip"
  source_dir  = "files"
  output_path = "files.zip"
}

The logs are as you'd expect:

$ terraform-0.13.3 apply -auto-approve
null_resource.create_file: Creating...
null_resource.create_file: Provisioning with 'local-exec'...
null_resource.create_file (local-exec): Executing: ["/bin/sh" "-c" "mkdir -p files && echo foo > files/test.txt"]
null_resource.create_file: Creation complete after 0s [id=6386526827814473963]
data.archive_file.foo: Reading...
data.archive_file.foo: Read complete after 0s [id=58aedda2be2144dcf22d3f5921c24ba616506a64]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Removing the depends_on argument fails as you'd expect too:

$ terraform-0.13.3 apply -auto-approve
data.archive_file.foo: Refreshing state... [id=58aedda2be2144dcf22d3f5921c24ba616506a64]
null_resource.create_file: Refreshing state... [id=6386526827814473963]

Error: error archiving directory: could not archive missing directory: files

  on main.tf line 11, in data "archive_file" "foo":
  11: data "archive_file" "foo" {

Do you see any significant difference between your initial configuration and this simpler reduction? Can you adjust this configuration to reproduce the bug?

NiklasKasper

comment created time in 4 days

issue commenthashicorp/terraform

Backend hash is updated too early

Thanks for reporting this, @lsierant! I'm able to confirm this with Terraform 0.13.3, using the folllowing steps:

  1. Create this main.tf:

    terraform {
      backend "local" {
        path = "./a.tfstate"
      }
    }
    
    resource "null_resource" "none" {}
    
  2. terraform init and terraform apply -auto-approve

  3. Change the backend configuration to path = "./b.tfstate" and remove the resource

  4. Run terraform init and hit ctrl-C

  5. Run terraform init again and it "succeeds" without confirmation

  6. Run terraform apply -auto-approve and the resource will be deleted from a.tfstate

As you found yourself, the issue looks like it is in the backend hash being updated too early/incorrectly. This is the same underlying issue as #23093. Unfortunately this area of code is very tricky to think through, so I don't have a clear solution at this time. Your failing test in #26260 is a great place to start for whoever picks this up next.

lsierant

comment created time in 4 days

issue closedhashicorp/terraform

"terraform console" incorrectly omits object and map elements whose values are null

Terraform Version

Terraform v0.12.16

Steps to Reproduce

$ terraform console
> {a=null}
{}
> keys({a=null})
[
  "a",
]
> keys({})
[]

Expected Behavior

Either {a=null} != {}, or keys({a=null}) == [].

closed time in 4 days

moio

issue commenthashicorp/terraform

"terraform console" incorrectly omits object and map elements whose values are null

This is fixed in #26189, which will be part of the Terraform 0.14.0 release.

Sample session with a build from today:

$ terraform console
> {a=null}
{
  "a" = null
}
> merge({"a"=1,"b"=2},{"a"=null,"c"=3})
{
  "a" = null
  "b" = 2
  "c" = 3
}
moio

comment created time in 4 days

issue commenthashicorp/terraform

The "count" value depends on resource attributes that cannot be determined until apply, but resource attributes are already applied

Thanks, @zachwhaley! 👍 I can reproduce the issue on 0.13.2 and 0.13.3.

The good news is that it appears to be fixed with a build from the latest main branch, due to #26270. I'm going to leave this issue open but expect this issue to be fixed with the release of 0.14.0.

dimisjim

comment created time in 4 days

issue commenthashicorp/terraform

v0.13.2 fails to import resources when interpolation is used in provider in module

Thanks for reporting this, @demonemia, and thanks for the reproduction repository. I'm able to reproduce the issue with Terraform 0.13.3.

I'm not sure what the cause is, but there are several other similar import bugs due to the import process not fully evaluating the configuration. Possibly related: #26258.

demonemia

comment created time in 4 days

issue commenthashicorp/terraform

Allow state mv to create new resources REOPENED

@gtmtech Thanks for reporting this and linking to the relevant issues!

I'm unable to reproduce this issue with Terraform 0.12.29 or 0.13.3. Here's what I tried:

  • Create main.tf:

    locals {
      nulls = toset(["foo", "bar"])
    }
    
    resource "null_resource" "null" {
    #  for_each = local.nulls
    }
    
  • terraform init, terraform apply -auto-approve to create the single resource

  • uncomment the for_each in the resource

  • terraform state mv null_resource.null 'null_resource.null["foo"]' to move the resource (success)

  • terraform plan shows that only the resource for "bar" needs to be created

Can you explain the difference between your configuration or steps and this one? If you can change these reproduction steps to show what you're seeing, that will help us identify the problem.

gtmtech

comment created time in 4 days

issue commenthashicorp/terraform

terraform import fails when modules use for_each

Thanks, that is very helpful! I have a slightly simpler reproduction case in our issue reproductions:

main.tf:

locals {
  xs = toset(["foo"])
}

module "a" {
  for_each = local.xs
  source   = "./a"
}

module "b" {
  for_each = local.xs
  source   = "./b"
  y = module.a[each.key].y
}

a/main.tf:

output "y" {
  value = "bar"
}

b/main.tf:

variable "y" {
  type = string
}

resource "random_pet" "pet" {
  prefix = var.y
}

Repro:

  • terraform init
  • (Optionally terraform apply but it doesn't change the behaviour)
  • terraform import -allow-missing-config random_string.test test

Result:

$ terraform-0.13.3 import -allow-missing-config random_string.test test
random_string.test: Importing from ID "test"...
random_string.test: Import prepared!
  Prepared random_string for import
random_string.test: Refreshing state... [id=test]

Error: Invalid index

  on /Users/alisdair/repro/26258/main.tf line 13, in module "b":
  13:   y = module.a[each.key].y
    |----------------
    | each.key is "foo"
    | module.a is object with no attributes

The given key does not identify an element in this collection value.

This worked in 0.13.0, and therefore may have been broken by #25890, but I'm not sure how to fix it. Marking as confirmed for now.

favoretti

comment created time in 4 days

push eventdanieldreier/terraform-issue-reproductions

Alisdair McDiarmid

commit sha eb62e7ea8ba36cf7ab5c83144c24ed5655fbde43

Repro for hashicorp/terraform#26258

view details

push time in 4 days

issue commenthashicorp/terraform

Crash when using Destroy

Can you try the following simple configuration on your host?

resource "null_resource" "none" {}

Please init, apply, and destroy with this configuration. This works for me with Terraform 0.13.3 on VirtualBox 6.1.12 on a macOS host with Ubuntu Server 20.04.1.

If that works, please try to create as simple a configuration as possible which does fail, so that we can try to reproduce the issue.

LunaticZorr

comment created time in 4 days

issue closedhashicorp/terraform

azurerm_kubernetes_cluster_node_pool allow setting node_count and min_count to 0

It is supporter via CLI

https://github.com/Azure/AKS/issues/1565

closed time in 5 days

Alexander-Bartosh

issue closedhashicorp/terraform

on-destroy remote-exec provisioner can not be executed within an aws_cloudformation_stack resource

Terraform Version

Terraform v0.13.1
+ provider registry.terraform.io/hashicorp/aws v3.5.0
+ provider registry.terraform.io/hashicorp/local v1.4.0
+ provider registry.terraform.io/hashicorp/null v2.1.2
+ provider registry.terraform.io/hashicorp/template v2.1.2
...

Terraform Configuration Files

<!-- Paste the relevant parts of your Terraform configuration between the ``` marks below.

For large Terraform configs, please use a service like Dropbox and share a link to the ZIP file. For security, you can also encrypt the files using our GPG public key. -->

resource "aws_cloudformation_stack" "bastion_stack" {
#...
  provisioner "remote-exec" {
    when = destroy
    connection {
      type        = "ssh"
      user        = "centos"
      private_key = file(var.ssh_private_key_file)
      host        = self.outputs["BastionHostIP"]
      agent       = false
    }
    inline = [
      "./cleanup.sh",
    ]
}

Debug Output

<!-- Full debug output can be obtained by running Terraform with the environment variable TF_LOG=trace. Please create a GitHub Gist containing the debug output. Please do not paste the debug output in the issue, since debug output is long.

Debug output may contain sensitive information. Please review it before posting publicly, and if you are concerned feel free to encrypt the files using the HashiCorp security public key. -->

Error: Invalid reference from destroy provisioner
in resource "aws_cloudformation_stack" "bastion_stack":
24: private_key = file(var.ssh_private_key_file)
Destroy-time provisioners and their connection configurations may only
reference attributes of the related resource, via 'self', 'count.index', or
'each.key'.
References to other resources during the destroy phase can cause dependency
cycles and interact poorly with create_before_destroy.

Crash Output

<!-- If the console output indicates that Terraform crashed, please share a link to a GitHub Gist containing the output of the crash.log file. -->

Expected Behavior

<!-- What should have happened? --> It should be able to execute on-destroy remote-exec provisioner in aws_cloudformation_stack

Actual Behavior

<!-- What actually happened? --> remote-exec not be executed

Steps to Reproduce

<!-- Please list the full steps required to reproduce the issue, for example:

  1. terraform init
  2. terraform apply --> terraform destroy

Additional Context

<!-- Are there anything atypical about your situation that we should know? For example: is Terraform running in a wrapper script or in a CI system? Are you passing any unusual command line options or environment variables to opt-in to non-default behavior? --> I tried to upgrade the terraform from 0.12.12 to a newer one, currently it ls 0.13.1. And previously, it worked in a non_resource to clean up some addition infras when destroy, for which were not created by terraform. After upgrade, it told me that it was not allowed to refer some other resource when destroy, it should be within the particular resource. so I moved it to the resource which provisioning a bastion that I need it to run the clean up script. Failed with errors.

References

<!-- Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

  • #6017

-->

closed time in 5 days

AlexSH001

issue commenthashicorp/terraform

on-destroy remote-exec provisioner can not be executed within an aws_cloudformation_stack resource

Hi @AlexSH001, thanks for reporting this issue.

This is intentional behaviour, added in #23559 as a deprecation and converted to an error in #24083. We added a section to the 0.13 upgrade guide which suggests a migration path forward for users who need destroy provisioners, using null_resource.

I'm marking this as closed because I believe it is working as intended.

AlexSH001

comment created time in 5 days

issue commenthashicorp/terraform

Crash when using Destroy

Thanks! I'm still not able to reproduce this error, and your file permissions seem like they should not be the problem.

A similar issue from the past is #15909, where the underlying cause was the execution environment in which Terraform was run preventing fork from succeeding. Perhaps that's the issue here.

Some more questions:

  • Can you say more about how you're using Terraform? Is it directly on a Linux host, or in a VM, or a Docker container?
  • Does the error occur with all Terraform configurations, or just one? If it's configuration related, can you share the Terraform configuration?
  • You mentioned that init and plan are fine, but destroy fails. Does terraform apply work?

Thanks for investigating this with us!

LunaticZorr

comment created time in 5 days

delete branch hashicorp/terraform

delete branch : alisdair/sensitive-variable-plan-tests

delete time in 5 days

push eventhashicorp/terraform

Alisdair McDiarmid

commit sha 9e340ab85bf02908e8c09578fb9c2bd717e615a9

terraform: Expand sensitive variable plan test Test that the changes which use the sensitive variable have corresponding path value marks. Also remove the unrelated validate function from this test.

view details

Alisdair McDiarmid

commit sha e1a41daf9bc1a47bfcf0aefa1fae0475840603b7

terraform: Test sensitive values in module inputs Passing a sensitive value as a module input variable should preserve its sensitivity for the plan.

view details

Alisdair McDiarmid

commit sha e77c3673452eae3e40e9b4d56d2f2eed14d1ab59

Merge pull request #26273 from hashicorp/alisdair/sensitive-variable-plan-tests Extend sensitive variable plan tests

view details

push time in 5 days

PR merged hashicorp/terraform

Extend sensitive variable plan tests

Two commits:

  • 9e340ab: Extend the existing sensitive variable plan test, to verify that attributes using sensitive values have appropriate path value marks stored. This is the best way I can think of to test that sensitivity is being preserved for plan outputs, short of an end-to-end test.
  • e1a41da: Add a test showing that sensitive variable values can be used as module input variables, while preserving sensitivity. Uses the same approach as above to verify this.

Note: the overall diff is really confusing. Thanks git! I'd recommend looking at each commit in turn for a clearer picture on what's changing.

+93 -6

1 comment

3 changed files

alisdair

pr closed time in 5 days

push eventhashicorp/terraform

Alisdair McDiarmid

commit sha 6ec34b1f445e7b0964bcdec639ce16cfc4f8922d

Update CHANGELOG.md

view details

push time in 5 days

delete branch hashicorp/terraform

delete branch : alisdair/more-interpolation-only-expression-deprecations-0.13

delete time in 5 days

push eventhashicorp/terraform

Alisdair McDiarmid

commit sha 68f64d2d28e75a265186cfd9c61674433cd70d37

configs: More interpolation-only expr deprecations Extend the deprecation for interpolation-only expressions to include module calls, data sources, outputs, and locals.

view details

Alisdair McDiarmid

commit sha a77ea742e6985368c18d58fd6f2c85bfe9dbe222

Merge pull request #26272 from hashicorp/alisdair/more-interpolation-only-expression-deprecations-0.13 configs: More interpolation-only expr deprecations

view details

push time in 5 days

PR merged hashicorp/terraform

configs: More interpolation-only expr deprecations

Extend the deprecation for interpolation-only expressions to include module calls, data sources, outputs, and locals.

Backport of #26105 to 0.13.

Changelog entry

UPGRADE NOTES:

  • Deprecated interpolation-only expressions are detected in more contexts in addition to resources and provider configurations. Module calls, data sources, outputs, and locals are now also covered. An expression like "${foo}" should be rewritten as just foo.
+48 -3

1 comment

4 changed files

alisdair

pr closed time in 5 days

issue commenthashicorp/terraform

0.13.x: Destroying resource with -target doesn't destroy resources defined in data blocks in module that depends on targeted resource

Hi @9numbernine9, thanks for reporting this. I'm able to reproduce the issue with your configuration and reproduction steps with Terraform 0.13.3.

While I understand your surprise at this behaviour, I don't believe that this is a bug. My understanding is that module depends_on is intended to delay the evaluation of a module, not create destroy edges that would be followed as part of a targeted destroy. The use of module depends_on is intended only to ensure that operations are executed in the required order, so I'm not surprised that the data source is not removed from state.

Resource targeting and especially targeted destroy are tools intended to be used in exceptional circumstances, so they may have a few rough edges. We recommend that users avoid using targeted destroy wherever possible.

I'm leaving this open and will ask other core team members to confirm or correct my understanding here.

9numbernine9

comment created time in 5 days

issue commenthashicorp/terraform

Terraform plan doesn't indicate security group removal

I can't reproduce this issue. Please provide your configuration, and more details.

Here is what I tried:

provider "aws" {
  region = "us-east-1"
}

resource "aws_security_group" "allow_egress" {
  name = "allow_egress"

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_security_group" "allow_ingress_ssh" {
  name = "allow_ingress_ssh"

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "web" {
  ami           = "ami-2757f631"
  instance_type = "t2.micro"

  security_groups = [
    aws_security_group.allow_egress.name,
    aws_security_group.allow_ingress_ssh.name
  ]
}

Apply this to create the two security groups and the instance. Then, change the aws_instance configuration to remove one of the groups:

resource "aws_instance" "web" {
  ami           = "ami-2757f631"
  instance_type = "t2.micro"

  security_groups = [
    aws_security_group.allow_ingress_ssh.name
  ]
}

The plan shows that the instance will be replaced:

Terraform will perform the following actions:

  # aws_instance.web must be replaced
-/+ resource "aws_instance" "web" {
        ami                          = "ami-2757f631"
      ~ arn                          = "arn:aws:ec2:us-east-1:201907987408:instance/i-03abbbbd4118073b5" -> (known after apply)
      ~ associate_public_ip_address  = true -> (known after apply)
      ~ availability_zone            = "us-east-1a" -> (known after apply)
      ~ cpu_core_count               = 1 -> (known after apply)
      ~ cpu_threads_per_core         = 1 -> (known after apply)
      - disable_api_termination      = false -> null
      - ebs_optimized                = false -> null
        get_password_data            = false
      - hibernation                  = false -> null
      + host_id                      = (known after apply)
      ~ id                           = "i-03abbbbd4118073b5" -> (known after apply)
      ~ instance_state               = "running" -> (known after apply)
        instance_type                = "t2.micro"
      ~ ipv6_address_count           = 0 -> (known after apply)
      ~ ipv6_addresses               = [] -> (known after apply)
      + key_name                     = (known after apply)
      - monitoring                   = false -> null
      + outpost_arn                  = (known after apply)
      + password_data                = (known after apply)
      + placement_group              = (known after apply)
      ~ primary_network_interface_id = "eni-041d465b4dd6df646" -> (known after apply)
      ~ private_dns                  = "ip-172-31-81-24.ec2.internal" -> (known after apply)
      ~ private_ip                   = "172.31.81.24" -> (known after apply)
      ~ public_dns                   = "ec2-18-207-190-237.compute-1.amazonaws.com" -> (known after apply)
      ~ public_ip                    = "18.207.190.237" -> (known after apply)
      ~ secondary_private_ips        = [] -> (known after apply)
      ~ security_groups              = [ # forces replacement
          - "allow_egress",
            "allow_ingress_ssh",
        ]
        source_dest_check            = true
      ~ subnet_id                    = "subnet-f9458cd8" -> (known after apply)
      - tags                         = {} -> null
      ~ tenancy                      = "default" -> (known after apply)
      ~ volume_tags                  = {} -> (known after apply)
      ~ vpc_security_group_ids       = [
          - "sg-01dce57cd065230ed",
          - "sg-07b8a21e374601dcd",
        ] -> (known after apply)

      - credit_specification {
          - cpu_credits = "standard" -> null
        }

      + ebs_block_device {
          + delete_on_termination = (known after apply)
          + device_name           = (known after apply)
          + encrypted             = (known after apply)
          + iops                  = (known after apply)
          + kms_key_id            = (known after apply)
          + snapshot_id           = (known after apply)
          + volume_id             = (known after apply)
          + volume_size           = (known after apply)
          + volume_type           = (known after apply)
        }

      + ephemeral_block_device {
          + device_name  = (known after apply)
          + no_device    = (known after apply)
          + virtual_name = (known after apply)
        }

      ~ metadata_options {
          ~ http_endpoint               = "enabled" -> (known after apply)
          ~ http_put_response_hop_limit = 1 -> (known after apply)
          ~ http_tokens                 = "optional" -> (known after apply)
        }

      + network_interface {
          + delete_on_termination = (known after apply)
          + device_index          = (known after apply)
          + network_interface_id  = (known after apply)
        }

      ~ root_block_device {
          ~ delete_on_termination = true -> (known after apply)
          ~ device_name           = "/dev/sda1" -> (known after apply)
          ~ encrypted             = false -> (known after apply)
          ~ iops                  = 100 -> (known after apply)
          + kms_key_id            = (known after apply)
          ~ volume_id             = "vol-0768c0103298b380c" -> (known after apply)
          ~ volume_size           = 8 -> (known after apply)
          ~ volume_type           = "gp2" -> (known after apply)
        }
    }

Plan: 1 to add, 0 to change, 1 to destroy.

Note this section of the diff:

      ~ security_groups              = [ # forces replacement
          - "allow_egress",
            "allow_ingress_ssh",
        ]
jzeggelaar

comment created time in 5 days

issue commenthashicorp/terraform

Provider installations fails when a provider has a non-zip archive in the release artifacts

Thanks for reporting this! I can reproduce the issue with the configuration you provided.

I believe this is a bug in the Terraform Registry. Terraform core intentionally only supports Zip archives, so I believe that the registry should not have ingressed the tarball, and certainly not have provided it as a download URL:

$ curl -s https://registry.terraform.io/v1/providers/louy/uptimerobot/0.5.0/download/linux/amd64 | jq -r .download_url
https://github.com/louy/terraform-provider-uptimerobot/releases/download/v0.5.0/terraform-provider-uptimerobot_0.5.0_linux_amd64.tar.gz

I'm glad you were able to find a workaround! I'm passing this upstream to the Terraform Registry maintainers.

louy

comment created time in 5 days

issue commenthashicorp/terraform

Crash when using Destroy

Thanks for reporting this, @LunaticZorr. That's a strange error.

Seeing "permission denied" seems to indicate that the provider plugin may not have the correct file permissions. Assuming you're on a UNIX-like environment, what is the output of ls -lR .terraform/plugins?

If the permissions are wrong, this would seem like an issue outside of Terraform's control. terraform init ensures that the permissions are correct on install, so if some external process is changing that, there's not much we can do. You might try removing the .terraform directory and rerunning init to see if it fixes the problem.

If you can post the full debug logs (removing any secrets) that might be helpful too.

LunaticZorr

comment created time in 5 days

issue closedhashicorp/terraform

Unable to deploy Azure Lighthouse using Terraform and ARM

Hi,

A few days ago I tried to deploy azure lighthouse using ARM and running the template with Terraform.

Terraform Version

Terraform v0.13.1 provider registry.terraform.io/hashicorp/azurerm v2.0.0

Terraform Configuration Files

# Configure the Azure Provider
provider azurerm {
  # whilst the `version` attribute is optional, we recommend pinning to a given version of the Provider
  version = "2.0.0"
  features {}
}

resource "azurerm_resource_group" "azurelighthousedeploy" {
  name     = "lighthouseRg"
  location = "North Europe"
}
resource "azurerm_template_deployment" "azurelighthousedeployment" {

  name                = "azurelighthousedeployment"
  resource_group_name = azurerm_resource_group.azurelighthousedeploy.name

  template_body = <<DEPLOY

{
    "$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentParameters.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "mspName": {
            "value": "Company"
        },
        "mspOfferDescription": {
            "value": "Company - Global Managed Services"
        },
        "managedByTenantId": {
            "value": "yyyyyyy-yyyyyyyy-yyyyyyyyy"
        },
        "authorizations": {
            "value": [
                {        
                "principalId": "yyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyy",
                "principalIdDisplayName": "team1",
                "roleDefinitionId": "yyyyyy-yyyy-yyyy-yyyy-yyyyyyyy"
                },
                {        
                "principalId": "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyy",
                "principalIdDisplayName": "team2",
                "roleDefinitionId": "yyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyy"
                }
            ]
        }
    }
}

DEPLOY


  # these key-value pairs are passed into the ARM Template's `parameters` block
  parameters = {
    "storageAccountType" = "Standard_GRS"
  }

  deployment_mode = "Incremental"
}


Actual Behavior

After the 'terraform apply'

Error: Error Expanding the template_body for Azure RM Template Deployment

Steps to Reproduce

  1. terraform init
  2. terraform plan
  3. terraform apply

closed time in 5 days

AmineBenbouzid

issue commenthashicorp/terraform

Unable to deploy Azure Lighthouse using Terraform and ARM

The source of this error is in the AzureRM provider, not Terraform core. As a result I believe the issue here (if any) is in the provider.

However, that code should only fail if your template_body is invalid JSON. The configuration you've given here seems to be a valid JSON string, so I don't think it should have failed. Is it possible there was a typo which you corrected before reporting the bug?

As a side note, when creating JSON for resource attributes, we strongly recommend using the jsonencode function. This allows you to write your data structure in native HCL, have your text editor and Terraform's parser validate it for correctness, and rely on Terraform to encode the JSON string. This allows you to find typos and other mistakes earlier.

I don't believe this is a bug in Terraform core, so I'm going to close it. If you're able to reproduce the same error, please report the bug in the provider repo. Thanks!

AmineBenbouzid

comment created time in 5 days

issue commenthashicorp/terraform

Terraform plan doesn't indicate security group removal

Hi @jzeggelaar, thanks for reporting this issue.

Unfortunately there isn't enough detail in your report for us to be able to understand the problem. Please fill out the issue template and include as much detail about your configuration as possible, so that we can reproduce the issue. Thanks!

jzeggelaar

comment created time in 5 days

issue commenthashicorp/terraform

terraform import fails when modules use for_each

Thanks for reporting this issue, @favoretti!

Unfortunately there isn't enough detail here to understand what the cause of the issue is. Can you provide a smaller but complete configuration which has the same effect, so that we can reproduce it? If possible please use resources from the null or random providers, to make reproduction simpler. Thanks!

favoretti

comment created time in 5 days

issue commenthashicorp/terraform

Module does not refresh data sources unless applied with a target

@favoretti Thanks for reporting this issue!

We are working on changes related to this, and while I'm not sure that this use case will be fixed, I'd like to be able to understand this issue. I've tried to reproduce it with local-only providers, and I haven't been able to do so. Can you help?

Here's my configuration:

variable "get_secrets" {
  type    = set(string)
  default = ["foo"]
}

data "null_data_source" "secrets" {
  for_each = var.get_secrets
  inputs = {
    secret = sha256(each.value)
  }
}

output "foo" {
  value = data.null_data_source.secrets["foo"].outputs.secret
}

This works as expected:

$ terraform-0.13.2 apply -auto-approve
data.null_data_source.secrets["foo"]: Refreshing state...

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

foo = 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae

If I then add a new output to the configuration like so:

output "bar" {
  value = data.null_data_source.secrets["bar"].outputs.secret
}

And run an apply including "bar" in the set of secret IDs, it also works:

$ terraform-0.13.2 apply -auto-approve -var 'get_secrets=["foo", "bar"]'
data.null_data_source.secrets["bar"]: Refreshing state...
data.null_data_source.secrets["foo"]: Refreshing state... [id=static]

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

bar = fcde2b2edba56bf408601fb721fe9b5c338d10ee429ea04fae5511b68fbf8fb9
foo = 2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae

Can you change this simple example to be more like yours, so that it reproduces the issue you're seeing?

Failing that, can you provide a more minimal example of the configuration you're using which exhibits the bug?

favoretti

comment created time in 5 days

issue closedhashicorp/terraform

postgresql_role trying to revoke when it shouldn't, and failing

I'm trying to add roles to the postgresql admin user that is created when the postgresql server is created in Azure.

The "plan" step looks correct:

~ roles = [ "azure_pg_admin", + "gfp_aiq_adm", + "gfp_attributemanager_adm", + "gfp_gfdmmanager_adm", + "gfp_lightspark_adm", + "gfp_mdmrelay_adm", + "gfp_rcs_adm", "gfp_ruleservice_adm", ] So the plan is to leave the azure_pg_admin role untouched, and the gfp_ruleservice_adm role... correctly... and to add the additional roles that I specified in the Terraform.

However, when the "apply" step is run, the following error occurs:

2020-09-16T09:14:08.6061271Z �[1m�[31mError: �[0m�[0m�[1mcould not revoke role azure_pg_admin from postgresqldev: pq: must be superuser to perform revoke role azure_pg_admin on server owner�[0m

So the issue is that the "apply" is doing something different to what the "plan" is saying. It's trying to revoke a role (and failing because it's not a superuser), but it shouldn't be trying to revoke that role as there is no change for that role in the "plan" file.

closed time in 5 days

waynejnicklin

issue commenthashicorp/terraform

postgresql_role trying to revoke when it shouldn't, and failing

This appears to be an issue related to the PostgreSQL provider, so I've asked Hashibot to move it over there.

waynejnicklin

comment created time in 5 days

issue closedhashicorp/terraform

Empty merge result with empty input after destroy

Terraform Version

Terraform v0.13.2
+ provider registry.terraform.io/hashicorp/tls v2.2.0

Terraform Configuration Files

locals {
  tls_keylist1 = {
    "test1-1" = { algorithm = "ECDSA" }
  }
  tls_keylist2 = {
    "test2-1" = { algorithm = "ECDSA" }
  }
}

resource "tls_private_key" "tls_keys1" {
  for_each = local.tls_keylist1

  algorithm = each.value.algorithm
}

resource "tls_private_key" "tls_keys2" {
  for_each = local.tls_keylist2

  algorithm = each.value.algorithm
}

output "tls_keys" {
  value = merge(tls_private_key.tls_keys1, tls_private_key.tls_keys2)
}

Expected Behavior

merge will return all remaining objects, when one of the inputs to merge gets empty.

Actual Behavior

merge result is empty, when one of the inputs to merge gets empty.

Steps to Reproduce

  1. terraform init
  2. terraform apply
  3. Empty one of the local maps:
locals {
  tls_keylist1 = {
#   "test1-1" = { algorithm = "ECDSA" }
  }
  tls_keylist2 = {
    "test2-1" = { algorithm = "ECDSA" }
  }
}
  1. terraform apply
  2. terraform apply

Additional Context

With the initial apply, everything works as expected:

Terraform will perform the following actions:

  # tls_private_key.tls_keys1["test1-1"] will be created
  + resource "tls_private_key" "tls_keys1" {
      + algorithm                  = "ECDSA"
      + ecdsa_curve                = "P224"
      + id                         = (known after apply)
      + private_key_pem            = (sensitive value)
      + public_key_fingerprint_md5 = (known after apply)
      + public_key_openssh         = (known after apply)
      + public_key_pem             = (known after apply)
      + rsa_bits                   = 2048
    }

  # tls_private_key.tls_keys2["test2-1"] will be created
  + resource "tls_private_key" "tls_keys2" {
      + algorithm                  = "ECDSA"
      + ecdsa_curve                = "P224"
      + id                         = (known after apply)
      + private_key_pem            = (sensitive value)
      + public_key_fingerprint_md5 = (known after apply)
      + public_key_openssh         = (known after apply)
      + public_key_pem             = (known after apply)
      + rsa_bits                   = 2048
    }

Plan: 2 to add, 0 to change, 0 to destroy.

tls_private_key.tls_keys1["test1-1"]: Creating...
tls_private_key.tls_keys2["test2-1"]: Creating...
tls_private_key.tls_keys2["test2-1"]: Creation complete after 0s [id=09bdf230615fda93e7acc5d2dce16b2963f156b2]
tls_private_key.tls_keys1["test1-1"]: Creation complete after 0s [id=e6c1bfd162e419c300f87313d528ebf917db8896]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Outputs:

tls_keys = {
  "test1-1" = {
    "algorithm" = "ECDSA"
    "ecdsa_curve" = "P224"
    "id" = "e6c1bfd162e419c300f87313d528ebf917db8896"
    "private_key_pem" = "-----BEGIN EC PRIVATE KEY-----\nMGgCAQEEHDmoj0hG1d5vJ/LvfaaLSXig0pwxlYLCzdEqnb2gBwYFK4EEACGhPAM6\nAAQke9vNeguf8Rr1Qve0BmgkMnQDFjfoqBkCvWSL5Vv6mC9nxom7xeQF8OcucVIO\n0jLn1ND9eg8Ozg==\n-----END EC PRIVATE KEY-----\n"
    "public_key_fingerprint_md5" = ""
    "public_key_openssh" = ""
    "public_key_pem" = "-----BEGIN PUBLIC KEY-----\nME4wEAYHKoZIzj0CAQYFK4EEACEDOgAEJHvbzXoLn/Ea9UL3tAZoJDJ0AxY36KgZ\nAr1ki+Vb+pgvZ8aJu8XkBfDnLnFSDtIy59TQ/XoPDs4=\n-----END PUBLIC KEY-----\n"
    "rsa_bits" = 2048
  }
  "test2-1" = {
    "algorithm" = "ECDSA"
    "ecdsa_curve" = "P224"
    "id" = "09bdf230615fda93e7acc5d2dce16b2963f156b2"
    "private_key_pem" = "-----BEGIN EC PRIVATE KEY-----\nMGgCAQEEHAzq+mlr0E1BxxUfgWR3JzyaDMOwZtcobPWY5CigBwYFK4EEACGhPAM6\nAAR7dyfyWGZGLyupIcivfhrg0FJ9xpErYcIy+rS0wknVy9MJNM++y8eSFjD9cDx9\nciTOpHEFFMvNpQ==\n-----END EC PRIVATE KEY-----\n"
    "public_key_fingerprint_md5" = ""
    "public_key_openssh" = ""
    "public_key_pem" = "-----BEGIN PUBLIC KEY-----\nME4wEAYHKoZIzj0CAQYFK4EEACEDOgAEe3cn8lhmRi8rqSHIr34a4NBSfcaRK2HC\nMvq0tMJJ1cvTCTTPvsvHkhYw/XA8fXIkzqRxBRTLzaU=\n-----END PUBLIC KEY-----\n"
    "rsa_bits" = 2048
  }
}

Then, when one of the local maps is emptied, it is expected that the removed objects get destroyed and the remaining objects are not touched. Up to and including the destroy of the removed objects this works as expected, but afterwards the merge output is unexpectedly empty:

Terraform will perform the following actions:

  # tls_private_key.tls_keys1["test1-1"] will be destroyed
  - resource "tls_private_key" "tls_keys1" {
      - algorithm       = "ECDSA" -> null
      - ecdsa_curve     = "P224" -> null
      - id              = "e6c1bfd162e419c300f87313d528ebf917db8896" -> null
      - private_key_pem = (sensitive value)
      - public_key_pem  = <<~EOT
            -----BEGIN PUBLIC KEY-----
            ME4wEAYHKoZIzj0CAQYFK4EEACEDOgAEJHvbzXoLn/Ea9UL3tAZoJDJ0AxY36KgZ
            Ar1ki+Vb+pgvZ8aJu8XkBfDnLnFSDtIy59TQ/XoPDs4=
            -----END PUBLIC KEY-----
        EOT -> null
      - rsa_bits        = 2048 -> null
    }

Plan: 0 to add, 0 to change, 1 to destroy.

Changes to Outputs:
  ~ tls_keys = {
      - test1-1 = {
          - algorithm                  = "ECDSA"
          - ecdsa_curve                = "P224"
          - id                         = "e6c1bfd162e419c300f87313d528ebf917db8896"
          - private_key_pem            = <<~EOT
                -----BEGIN EC PRIVATE KEY-----
                MGgCAQEEHDmoj0hG1d5vJ/LvfaaLSXig0pwxlYLCzdEqnb2gBwYFK4EEACGhPAM6
                AAQke9vNeguf8Rr1Qve0BmgkMnQDFjfoqBkCvWSL5Vv6mC9nxom7xeQF8OcucVIO
                0jLn1ND9eg8Ozg==
                -----END EC PRIVATE KEY-----
            EOT
          - public_key_fingerprint_md5 = ""
          - public_key_openssh         = ""
          - public_key_pem             = <<~EOT
                -----BEGIN PUBLIC KEY-----
                ME4wEAYHKoZIzj0CAQYFK4EEACEDOgAEJHvbzXoLn/Ea9UL3tAZoJDJ0AxY36KgZ
                Ar1ki+Vb+pgvZ8aJu8XkBfDnLnFSDtIy59TQ/XoPDs4=
                -----END PUBLIC KEY-----
            EOT
          - rsa_bits                   = 2048
        } -> null
        test2-1 = {
            algorithm                  = "ECDSA"
            ecdsa_curve                = "P224"
            id                         = "09bdf230615fda93e7acc5d2dce16b2963f156b2"
            private_key_pem            = <<~EOT
                -----BEGIN EC PRIVATE KEY-----
                MGgCAQEEHAzq+mlr0E1BxxUfgWR3JzyaDMOwZtcobPWY5CigBwYFK4EEACGhPAM6
                AAR7dyfyWGZGLyupIcivfhrg0FJ9xpErYcIy+rS0wknVy9MJNM++y8eSFjD9cDx9
                ciTOpHEFFMvNpQ==
                -----END EC PRIVATE KEY-----
            EOT
            public_key_fingerprint_md5 = ""
            public_key_openssh         = ""
            public_key_pem             = <<~EOT
                -----BEGIN PUBLIC KEY-----
                ME4wEAYHKoZIzj0CAQYFK4EEACEDOgAEe3cn8lhmRi8rqSHIr34a4NBSfcaRK2HC
                Mvq0tMJJ1cvTCTTPvsvHkhYw/XA8fXIkzqRxBRTLzaU=
                -----END PUBLIC KEY-----
            EOT
            rsa_bits                   = 2048
        }
    }

tls_private_key.tls_keys1["test1-1"]: Destroying... [id=e6c1bfd162e419c300f87313d528ebf917db8896]
tls_private_key.tls_keys1["test1-1"]: Destruction complete after 0s

Apply complete! Resources: 0 added, 0 changed, 1 destroyed.

Please note the missing outputs. The state is now empty too:

{
  "version": 4,
  "terraform_version": "0.13.2",
  ...
  "outputs": {},
  ...
}

Just with the next apply the missing objects appear again:

Terraform will perform the following actions:

Plan: 0 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + tls_keys = {
      + test2-1 = {
          + algorithm                  = "ECDSA"
          + ecdsa_curve                = "P224"
          + id                         = "09bdf230615fda93e7acc5d2dce16b2963f156b2"
          + private_key_pem            = <<~EOT
                -----BEGIN EC PRIVATE KEY-----
                MGgCAQEEHAzq+mlr0E1BxxUfgWR3JzyaDMOwZtcobPWY5CigBwYFK4EEACGhPAM6
                AAR7dyfyWGZGLyupIcivfhrg0FJ9xpErYcIy+rS0wknVy9MJNM++y8eSFjD9cDx9
                ciTOpHEFFMvNpQ==
                -----END EC PRIVATE KEY-----
            EOT
          + public_key_fingerprint_md5 = ""
          + public_key_openssh         = ""
          + public_key_pem             = <<~EOT
                -----BEGIN PUBLIC KEY-----
                ME4wEAYHKoZIzj0CAQYFK4EEACEDOgAEe3cn8lhmRi8rqSHIr34a4NBSfcaRK2HC
                Mvq0tMJJ1cvTCTTPvsvHkhYw/XA8fXIkzqRxBRTLzaU=
                -----END PUBLIC KEY-----
            EOT
          + rsa_bits                   = 2048
        }
    }

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

tls_keys = {
  "test2-1" = {
    "algorithm" = "ECDSA"
    "ecdsa_curve" = "P224"
    "id" = "09bdf230615fda93e7acc5d2dce16b2963f156b2"
    "private_key_pem" = "-----BEGIN EC PRIVATE KEY-----\nMGgCAQEEHAzq+mlr0E1BxxUfgWR3JzyaDMOwZtcobPWY5CigBwYFK4EEACGhPAM6\nAAR7dyfyWGZGLyupIcivfhrg0FJ9xpErYcIy+rS0wknVy9MJNM++y8eSFjD9cDx9\nciTOpHEFFMvNpQ==\n-----END EC PRIVATE KEY-----\n"
    "public_key_fingerprint_md5" = ""
    "public_key_openssh" = ""
    "public_key_pem" = "-----BEGIN PUBLIC KEY-----\nME4wEAYHKoZIzj0CAQYFK4EEACEDOgAEe3cn8lhmRi8rqSHIr34a4NBSfcaRK2HC\nMvq0tMJJ1cvTCTTPvsvHkhYw/XA8fXIkzqRxBRTLzaU=\n-----END PUBLIC KEY-----\n"
    "rsa_bits" = 2048
  }
}

Additional info:

The provided code above is for simple reproduction. In the real code merge is used on a cloud resource, like shown:

resource "hcloud_ssh_key" "ssh_keys" {
  for_each = merge(
    { for name, data in tls_private_key.ssh_keys : name => data.public_key_openssh },
    { for name, data in data.local_file.ssh_public_keys : name => data.content }
  )

  name       = each.key
  public_key = each.value
}

There, when one of the merge inputs get empty due to destroyed objects, Terraform fails (after the actual destroy) with the following error:

Error: each.value cannot be used in this context

  on main.tf line 87, in resource "hcloud_ssh_key" "ssh_keys":
  87:   public_key = each.value

A reference to "each.value" has been used in a context in which it
unavailable, such as when the configuration no longer contains the value in
its "for_each" expression. Remove this reference to each.value in your
configuration to work around this error.

Interestingly, this error never occurs with create_before_destroy = true.

References

  • https://discuss.hashicorp.com/t/empty-merge-after-partial-destroy/13815

closed time in 5 days

peterpramb

issue commenthashicorp/terraform

Empty merge result with empty input after destroy

@peterpramb Thank you for this excellent reproduction case!

I was able to confirm this issue on Terraform 0.13.2. Happily, it seems to be fixed as of Terraform 0.13.3, I believe due to #26264. As a result, I'm marking this issue as closed, but if the bug in your real configuration still exists, please do comment here or open another issue so that we can investigate further.

peterpramb

comment created time in 5 days

issue commenthashicorp/terraform

The "count" value depends on resource attributes that cannot be determined until apply, but resource attributes are already applied

@dimisjim Thanks for reporting this!

Unfortunately I am having trouble understanding your report and following the reproduction steps. The configuration you provided seems to be missing some variable values, and is quite complex. So that we can reproduce and fix this issue, can you help me create a smaller reproduction configuration?

Here is what I've tried, which is based on my understanding of your report:

main.tf:

module "a" {
  source    = "./child"
  name      = "a"
  input_ids = ["test"]
}

module "b" {
  source    = "./child"
  name      = "b"
  input_ids = module.a.ids
}

child/main.tf:

variable "name" {
  type = string
}

variable "input_ids" {
  type    = list(string)
  default = []
}

locals {
  enabled = length(var.input_ids) > 0
}

resource "null_resource" "x" {
  count = local.enabled ? 1 : 0
}

output "ids" {
  value = null_resource.x.*.id
}

Unfortunately this successfully plans, even from an empty state. As you can see, the module outputs are not copied through as outputs from the root module, which I think is what you identified as the problem you saw.

Can you modify this configuration to make it similar to your own and reproduce the bug? Failing that, can you simplify your original configuration, ideally using null_resource, and provide an isolation reproduction case?

Thanks in advance for your help!

dimisjim

comment created time in 5 days

issue closedhashicorp/terraform

terraform --version has different standar output on different platforms.

The standar output is not consistent between platforms.

Examples below

OSx

terraform --version
Terraform v0.12.26

Your version of Terraform is out of date! The latest version
is 0.13.2. You can update by downloading from https://www.terraform.io/downloads.html

Linux

terraform --version
Your version of Terraform is out of date! The latest version
is 0.13.3. You can update by downloading from https://www.terraform.io/downloads.html
Terraform v0.13.0

this can lead to misunderstanding

Kind regards, Serafeim

closed time in 5 days

serafeimgr

issue commenthashicorp/terraform

terraform --version has different standar output on different platforms.

This is a bug in Terraform 0.13.0 which was fixed in #25811 and released as part of Terraform 0.13.1. Please try again with the latest Terraform release to see the fix.

serafeimgr

comment created time in 5 days

issue closedhashicorp/terraform

Errant "Changes to Outputs" shown with resource targeting as of 0.13

<!-- Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

If your issue relates to a specific Terraform provider, please open it in the provider's own repository. The index of providers is at https://github.com/terraform-providers . -->

Terraform Version

<!--- Run terraform version to show the version, and paste the result between the ``` marks below.

If you are not running the latest version of Terraform, please try upgrading because your issue may have already been fixed. -->

Terraform v0.13.1
+ provider registry.terraform.io/hashicorp/archive v1.3.0
+ provider registry.terraform.io/hashicorp/aws v3.4.0
+ provider registry.terraform.io/hashicorp/template v2.1.2

Expected Behavior

<!-- What should have happened? -->

I am applying changes to an aws_elastic_beanstalk_environment resource by targeting that particular resource. In the plan which is shown (prior to me having to type "yes"), I expect to see only the relevant targeted resources.

Actual Behavior

<!-- What actually happened? -->

What's shown in the output are the below changes to outputs (some details obfuscated). There are no changes to outputs in my Terraform configuration.

Plan: 0 to add, 1 to change, 0 to destroy.

Changes to Outputs:
  - bastion_dns              = [
      - [
          - "bastion-us-east-1a.example.com",
          - "bastion-us-east-1b.example.com",
          - "bastion-us-east-1c.example.com",
        ],
    ] -> null
  - foo_subnet_ids = [
      - [
          - "subnet-0abcdeabcdeed50c3",
          - "subnet-0abcdeabcdeed7167",
          - "subnet-0abcdeabcdeed195f",
        ],
    ] -> null
  - private_subnet_ids       = [
      - [
          - "subnet-abcdefb6",
          - "subnet-abcdef8b",
          - "subnet-abcdef41",
        ],
    ] -> null


Warning: Resource targeting is in effect

Steps to Reproduce

<!-- Please list the full steps required to reproduce the issue, for example:

  1. terraform init
  2. terraform apply -->

Use -target as of Terraform 0.13. This issue did not occur with prior versions.

closed time in 5 days

mrubinwch

issue commenthashicorp/terraform

Errant "Changes to Outputs" shown with resource targeting as of 0.13

This looks like a duplicate of #26274, which has a reproduction and an explanation. Closing.

mrubinwch

comment created time in 5 days

issue commenthashicorp/terraform

Terraform 0.13 complains that all list elements must have the same type, while 0.12 does not.

Thanks for reporting this @marcosdiez. I can't reproduce the issue without more information.

Can you provide a small configuration that I can use to reproduce the error message?

marcosdiez

comment created time in 6 days

PR opened hashicorp/terraform

Reviewers
Extend sensitive variable plan tests

Two commits:

  • 9e340ab: Extend the existing sensitive variable plan test, to verify that attributes using sensitive values have appropriate path value marks stored. This is the best way I can think of to test that sensitivity is being preserved for plan outputs, short of an end-to-end test.
  • e1a41da: Add a test showing that sensitive variable values can be used as module input variables, while preserving sensitivity. Uses the same approach as above to verify this.

Note: the overall diff is really confusing. Thanks git! I'd recommend looking at each commit in turn for a clearer picture on what's changing.

+93 -6

0 comment

3 changed files

pr created time in 6 days

create barnchhashicorp/terraform

branch : alisdair/sensitive-variable-plan-tests

created branch time in 6 days

PR opened hashicorp/terraform

configs: More interpolation-only expr deprecations

Extend the deprecation for interpolation-only expressions to include module calls, data sources, outputs, and locals.

Backport of #26105 to 0.13.

Changelog entry

UPGRADE NOTES:

  • Deprecated interpolation-only expressions are detected in more contexts in addition to resources and provider configurations. Module calls, data sources, outputs, and locals are now also covered. An expression like "${foo}" should be rewritten as just foo.
+48 -3

0 comment

4 changed files

pr created time in 6 days

delete branch hashicorp/terraform

delete branch : alisdair/more-interpolation-only-expression-deprecations

delete time in 6 days

push eventhashicorp/terraform

Alisdair McDiarmid

commit sha e693c14e5a67e9a273ef3fe523346d05be09991b

configs: More interpolation-only expr deprecations Extend the deprecation for interpolation-only expressions to include module calls, data sources, outputs, and locals.

view details

Alisdair McDiarmid

commit sha 803c95e5521d33db15b068fe6f0fb5be7ad8b79b

Merge pull request #26105 from hashicorp/alisdair/more-interpolation-only-expression-deprecations configs: More interpolation-only expr deprecations

view details

push time in 6 days

issue closedhashicorp/terraform

Terraform Validate does not throw warnings for deprecated syntax inside modules

<!-- Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

If your issue relates to a specific Terraform provider, please open it in the provider's own repository. The index of providers is at https://github.com/terraform-providers . -->

Terraform Version

Tested on multiple 0.12 versions, current version is 0.12.23

Terraform Configuration Files

I would expect the following foo = "${var.hello}" to throw a deprecation warning, but none is shown Repository created here https://github.com/Jimmyscene/terraform_bug

module "foo" {
  source = "../foo"
  foo    = "${var.hello}" # THIS DOES NOT ERROR?
}

Debug Output

https://gist.github.com/Jimmyscene/41408d647e1d31955d09774de5e7a0af

Expected Behavior

Warning: Interpolation-only expressions are deprecated

  on ../bar/main.tf line 6, in provider "null":
   7:  foo    = "${var.hello}" # THIS DOES NOT ERROR?

  on ../foo/main.tf line 6, in provider "null":
   6:   acceptable = "${var.foo}" # WARNING: Interpolation-only expressions are deprecated

Actual Behavior

Warning: Interpolation-only expressions are deprecated

  on ../foo/main.tf line 6, in provider "null":
   6:   acceptable = "${var.foo}" # WARNING: Interpolation-only expressions are deprecated

Steps to Reproduce

  1. Clone down repository linked above
  2. cd bar
  3. terraform init
  4. terraform validate

closed time in 6 days

Jimmyscene

PR merged hashicorp/terraform

configs: More interpolation-only expr deprecations

Extend the deprecation for interpolation-only expressions to include module calls, data sources, outputs, and locals.

This PR is targeting the 0.14.0 release. If merged, I'm not sure if it should be cherry-picked to 0.13.x or not. Thoughts?

Fixes #25430, fixes #25828, supersedes #25465.

+48 -3

1 comment

4 changed files

alisdair

pr closed time in 6 days

issue closedhashicorp/terraform

Terraform syntax warnings do not check data source or output blocks

The terraform init and terraform validate commands output syntax warnings for deprecated interpolation syntax for resources, but do not return warnings when the deprecated interpolation is on data source or output blocks.

Terraform Version

<!--- Run terraform version to show the version, and paste the result between the ``` marks below.

If you are not running the latest version of Terraform, please try upgrading because your issue may have already been fixed. -->

This error occurs in both 0.12 and 0.13

$ terraform version
Terraform v0.12.29
+ provider.aws v3.1.0
$ terraform version
Terraform v0.13.0
+ provider registry.terraform.io/hashicorp/aws v3.1.0

Terraform Configuration Files

<!-- Paste the relevant parts of your Terraform configuration between the ``` marks below.

For large Terraform configs, please use a service like Dropbox and share a link to the ZIP file. For security, you can also encrypt the files using our GPG public key. -->

variable "api_gateway_name" {
  type = string
}

data "aws_api_gateway_rest_api" "selected" {
  name = "${var.api_gateway_name}"
}

data "aws_cognito_user_pools" "selected" {
  name = "selected"
}

resource "aws_api_gateway_authorizer" "cognito" {
  name          = "cognito"
  type          = "COGNITO_USER_POOLS"
  rest_api_id   = "${data.aws_api_gateway_rest_api.selected.id}"
  provider_arns = data.aws_cognito_user_pools.selected.arns
}

output "api_id" {
  value = "${aws_api_gateway_authorizer.cognito.rest_api_id}"
}

Expected Behavior

The warning

Warning: Interpolation-only expressions are deprecated

should be generated for

  • data source aws_api_gateway_rest_api.selected name
  • resource aws_api_gateway_authorizer.cognito rest_api_id
  • output api_id value

Actual Behavior

The warning

Warning: Interpolation-only expressions are deprecated

is only generated for

  • resource aws_api_gateway_authorizer.cognito rest_api_id

Steps to Reproduce

<!-- Please list the full steps required to reproduce the issue, for example:

  1. terraform init

  2. terraform apply -->

  3. terraform init

  4. (Optionally) terraform validate

closed time in 6 days

gdavison

Pull request review commenthashicorp/terraform

Add bug triage guide

+# Terraform Core GitHub Bug Triage & Labeling+The Terraform Core team has adopted a more structured bug triage process than we previously used. Our goal is to respond to reports of issues quickly.++## Goal+We see working on Terraform as a collaborative process with the community of users. When people find bugs, or run into trouble using Terraform, we want to help.++When a bug report is filed, our goal is to either:+1. Get it to a state where it is ready for engineering to fix it in an upcoming Terraform release, or +2. Close it explain why, if we can't help++The intent of this process is to resolve issues quickly, either by getting them to a state where engineers can fix them, or by closing them when reproduction and resolution is not possible based on available information. +++## Process++### 1. [Newly created issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Anew+label%3Abug+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3A%22waiting+for+reproduction%22+-label%3A%22waiting-response%22+-label%3Aexplained) require initial filtering. ++**Goal**: Most issues triaged within a few days, and no issues should stay in this state for more than 7 days++These are raw reports that need categorization and support clarifying them. They need the following done:++* label backends, provisioners, providers so we can appropriately route work on codebases we don't support to the correct teams+* point requests for help to the community forum and close the issue+* close reports against 0.11+* prompt users who have submitted obviously incomplete reproduction cases for additional information+* If an issue requires discussion with the user to get it out of this initial state, leave "new" on there and label it "waiting-response" until this phase of triage is done.++Once this initial filtering has been done, remove the new label. If an issue subjectively looks very high-impact and likely to impact many users, add it to the [0.13.x milestone](https://github.com/hashicorp/terraform/milestone/17) to mark it as being urgent. ++### 2. Prompt reproduction cases for unreproduced issues++Many bug reports, as originally reported, describe valid issues, but are not detailed enough for engineers to fix. At this stage, we work with people who report bugs to generate clear reproduction cases. ++A core team member initially determines whether the issue is immediately reproducible. If they cannot readily reproduce it, they label it "waiting for reproduction" and correspond with the reporter to describe what is needed. When the issue is reproduced by a core team member, they label it "confirmed". ++"confirmed" issues should have a clear reproduction case, not just be one-off reproduced by someone on the team. Anyone who picks it up should be able to reproduce it readily without having to invent any details.++### Goals for unreproduced issues+In May 2020, we decided to draw a line and prioritize issues newer than that date, and gradually work down the remaining backlog over time.++1. for [unreproduced issues reported since May 2020](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+created%3A%3E2020-05-01+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Acreated-asc), we want to keep this number at zero, and have a goal of no issues of older than one month. The issues may not get fixed within a month, but they should either get to a reproducible state or be closed to clear out this queue.++2. For [unreproduced issues reported before May 2020](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+created%3A%3C2020-05-01+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Areactions-%2B1-desc), we want to reduce this number over time. We will roughly prioritize these by upvotes. However, many of the highest-voted issues are also some of the hardest to fix. We strictly prioritize staying on top of new issues.+++### 3. Explain or fix [confirmed issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+)+The next step for confirmed issues is to either:++* explain why the behavior is expected, label the issue as "working as designed", and close it, or+* locate the cause of the defect in the codebase. When the defect is located, and that description is posted on the issue, the issue is labeled "explained". In many cases, this step will get skipped if the fix is obvious, and engineers will jump forward and make a PR. ++#### Goals+Bugs with a high impact with widespread impact should be fixed in the next Z release.++1. All [confirmed crashes](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Acrash+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+) should be fixed in each Z release, even if they are unlikely to have a widespread impact+2. [confirmed non-crash bugs](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+-label%3Adocumentation+-label%3Acrash+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+sort%3Areactions-%2B1-desc) should be resolved roughly in order of upvotes. Most of these issues should be fixed within 4 weeks, and issues that are blocked on needing a larger research or refactor project should have a brief explanation posted and be labeled "pending project"++### 4. The last step for [explained issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+label%3Aexplained+no%3Amilestone+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+) is to make a PR to fix them. ++The issue can be closed and labeled "fixed" after the PR is merged, even if it's not included in a release yet. Since issues can be closed automatically when linked from a PR, labeling them as fixed is not mandatory. This is a convenience to exclude them from these triage filter search results.++Explained issues that are expected to be fixed in a future release should have a milestone++#### Goals+* All explained issues should be fixed or assigned to a future milestone by the time the release candidate of the next major release ships++## GitHub Issue Labels+label                    | description+------------------------ | -----------+new                      | new issue not yet triaged+explained                | a Terraform Core team member has described the root cause of this issue in code+waiting for reproduction | unable to reproduce issue without further information +not reproducible         | closed because a reproduction case could not be generated+duplicate                | issue closed because another issue already tracks this problem+confirmed                | a Terraform Core team member has reproduced this issue+working as designed      | confirmed as reported and closed because the behavior is intended+fixed                    | issue is fixed by PR that has been merged+pending project          | issue is confirmed but will require a significant project to fix++## What is a good reproduction case?++A reproduction case must be something a Terraform Core engineer can git-clone or copy-paste and run immediately, without inventing any details or context. ++### How to write a good reproduction case++* A short example can be directly copy-pasteable; longer examples should be in separate git repositories, especially if multiple files are needed+* Include all needed context. For example, if you figured out that an expression can cause a crash, put the expression in a variable definition or a resource+* Set defaults on (or omit) any needed variables. The person reproducing it should not need to invent variable settings+* If multiple steps are required, such as running terraform twice, consider scripting it in a simple shell script. For example, see [this case](https://github.com/danieldreier/terraform-issue-reproductions/tree/master/25719). Providing a script can be easier than explaining what changes to make to the config between runs.+* Omit any unneeded complexity: remove variables, conditional statements, functions, modules, providers, and resources that are not needed to trigger the bug+* When possible, use the [null resource](https://www.terraform.io/docs/providers/null/resource.html) provider rather than a real provider in order to minimize external dependencies. We know this isn't always feasible. The Terraform Core team doesn't have deep domain knowledge in every provider, or access to every cloud platform for reproduction cases.++## Lack of response and unreproducible issues+When bugs that have been [labeled waiting response](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3A%22waiting+for+reproduction%22+label%3Awaiting-response+-label%3Aexplained+sort%3Aupdated-asc) or [labeled "waiting for reproduction"](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+label%3A%22waiting+for+reproduction%22+-label%3Aexplained+sort%3Aupdated-asc+) for more than 30 days, we'll use our best judgement to determine whether it's more helpful to close it or prompt the reporter again. If they again go without a response for 30 days, they can be closed with a polite message explaining why and inviting the person to submit the needed information or reproduction case in the future.++The intent of this process is to get fix the maximum number of bugs in Terraform as quickly as possible, and having un-actionable bug reports makes it harder for Terraform Core team members and community contributors to find bugs they can actually work on.++## Helpful GitHub Filters++[Confirmed needs for documentation fixes](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+label%3Adocumentation++label%3Aconfirmed+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+)++[Confirmed bugs that will require significant projects to fix](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+label%3Aconfirmed+label%3A%22pending+project%22++-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2)++### By Milestone+[0.13.x Milestone](https://github.com/hashicorp/terraform/milestone/17). Issues in this milestone should be considered high-priority but do not block a Z release. All issues in this milestone should be resolved in a 13.x release before the 0.14.0 RC1 ships.+[0.14.0 Milestone](https://github.com/hashicorp/terraform/milestone/18). All issues in this milestone must be fixed before 0.14.0 RC1 ships, and should ideally be fixed before 0.14.0 beta 1 ships.+[0.15.0 Milestone](https://github.com/hashicorp/terraform/milestone/19). All issues in this milestone must be fixed before 0.15.0 RC1 ships, and should ideally be fixed before 0.15.0 beta 1 ships.

Could we add a sentence explaining that this is an example of the milestones to explain how they're to be used? Otherwise we'll need to remember to update this document after shipping 0.14.0.

danieldreier

comment created time in 6 days

Pull request review commenthashicorp/terraform

Add bug triage guide

+# Terraform Core GitHub Bug Triage & Labeling+The Terraform Core team has adopted a more structured bug triage process than we previously used. Our goal is to respond to reports of issues quickly.++## Goal+We see working on Terraform as a collaborative process with the community of users. When people find bugs, or run into trouble using Terraform, we want to help.++When a bug report is filed, our goal is to either:+1. Get it to a state where it is ready for engineering to fix it in an upcoming Terraform release, or +2. Close it explain why, if we can't help++The intent of this process is to resolve issues quickly, either by getting them to a state where engineers can fix them, or by closing them when reproduction and resolution is not possible based on available information. +++## Process++### 1. [Newly created issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Anew+label%3Abug+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3A%22waiting+for+reproduction%22+-label%3A%22waiting-response%22+-label%3Aexplained) require initial filtering. ++**Goal**: Most issues triaged within a few days, and no issues should stay in this state for more than 7 days++These are raw reports that need categorization and support clarifying them. They need the following done:++* label backends, provisioners, providers so we can appropriately route work on codebases we don't support to the correct teams+* point requests for help to the community forum and close the issue+* close reports against 0.11+* prompt users who have submitted obviously incomplete reproduction cases for additional information+* If an issue requires discussion with the user to get it out of this initial state, leave "new" on there and label it "waiting-response" until this phase of triage is done.++Once this initial filtering has been done, remove the new label. If an issue subjectively looks very high-impact and likely to impact many users, add it to the [0.13.x milestone](https://github.com/hashicorp/terraform/milestone/17) to mark it as being urgent. ++### 2. Prompt reproduction cases for unreproduced issues++Many bug reports, as originally reported, describe valid issues, but are not detailed enough for engineers to fix. At this stage, we work with people who report bugs to generate clear reproduction cases. ++A core team member initially determines whether the issue is immediately reproducible. If they cannot readily reproduce it, they label it "waiting for reproduction" and correspond with the reporter to describe what is needed. When the issue is reproduced by a core team member, they label it "confirmed". ++"confirmed" issues should have a clear reproduction case, not just be one-off reproduced by someone on the team. Anyone who picks it up should be able to reproduce it readily without having to invent any details.++### Goals for unreproduced issues+In May 2020, we decided to draw a line and prioritize issues newer than that date, and gradually work down the remaining backlog over time.++1. for [unreproduced issues reported since May 2020](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+created%3A%3E2020-05-01+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Acreated-asc), we want to keep this number at zero, and have a goal of no issues of older than one month. The issues may not get fixed within a month, but they should either get to a reproducible state or be closed to clear out this queue.++2. For [unreproduced issues reported before May 2020](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+created%3A%3C2020-05-01+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Areactions-%2B1-desc), we want to reduce this number over time. We will roughly prioritize these by upvotes. However, many of the highest-voted issues are also some of the hardest to fix. We strictly prioritize staying on top of new issues.+++### 3. Explain or fix [confirmed issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+)+The next step for confirmed issues is to either:++* explain why the behavior is expected, label the issue as "working as designed", and close it, or+* locate the cause of the defect in the codebase. When the defect is located, and that description is posted on the issue, the issue is labeled "explained". In many cases, this step will get skipped if the fix is obvious, and engineers will jump forward and make a PR. ++#### Goals+Bugs with a high impact with widespread impact should be fixed in the next Z release.++1. All [confirmed crashes](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Acrash+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+) should be fixed in each Z release, even if they are unlikely to have a widespread impact+2. [confirmed non-crash bugs](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+-label%3Adocumentation+-label%3Acrash+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+sort%3Areactions-%2B1-desc) should be resolved roughly in order of upvotes. Most of these issues should be fixed within 4 weeks, and issues that are blocked on needing a larger research or refactor project should have a brief explanation posted and be labeled "pending project"++### 4. The last step for [explained issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+label%3Aexplained+no%3Amilestone+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+) is to make a PR to fix them. ++The issue can be closed and labeled "fixed" after the PR is merged, even if it's not included in a release yet. Since issues can be closed automatically when linked from a PR, labeling them as fixed is not mandatory. This is a convenience to exclude them from these triage filter search results.

I think fixed is completely redundant with is:open, unless we really want to report on the difference between issues that were unreproducible and closed and those which were reproduced and fixed. I'd advocate for removing the label and references to it for simplicity.

danieldreier

comment created time in 6 days

Pull request review commenthashicorp/terraform

Add bug triage guide

+# Terraform Core GitHub Bug Triage & Labeling+The Terraform Core team has adopted a more structured bug triage process than we previously used. Our goal is to respond to reports of issues quickly.++## Goal+We see working on Terraform as a collaborative process with the community of users. When people find bugs, or run into trouble using Terraform, we want to help.++When a bug report is filed, our goal is to either:+1. Get it to a state where it is ready for engineering to fix it in an upcoming Terraform release, or +2. Close it explain why, if we can't help++The intent of this process is to resolve issues quickly, either by getting them to a state where engineers can fix them, or by closing them when reproduction and resolution is not possible based on available information. +++## Process++### 1. [Newly created issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Anew+label%3Abug+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3A%22waiting+for+reproduction%22+-label%3A%22waiting-response%22+-label%3Aexplained) require initial filtering. ++**Goal**: Most issues triaged within a few days, and no issues should stay in this state for more than 7 days++These are raw reports that need categorization and support clarifying them. They need the following done:++* label backends, provisioners, providers so we can appropriately route work on codebases we don't support to the correct teams+* point requests for help to the community forum and close the issue+* close reports against 0.11+* prompt users who have submitted obviously incomplete reproduction cases for additional information+* If an issue requires discussion with the user to get it out of this initial state, leave "new" on there and label it "waiting-response" until this phase of triage is done.++Once this initial filtering has been done, remove the new label. If an issue subjectively looks very high-impact and likely to impact many users, add it to the [0.13.x milestone](https://github.com/hashicorp/terraform/milestone/17) to mark it as being urgent. ++### 2. Prompt reproduction cases for unreproduced issues++Many bug reports, as originally reported, describe valid issues, but are not detailed enough for engineers to fix. At this stage, we work with people who report bugs to generate clear reproduction cases. ++A core team member initially determines whether the issue is immediately reproducible. If they cannot readily reproduce it, they label it "waiting for reproduction" and correspond with the reporter to describe what is needed. When the issue is reproduced by a core team member, they label it "confirmed". ++"confirmed" issues should have a clear reproduction case, not just be one-off reproduced by someone on the team. Anyone who picks it up should be able to reproduce it readily without having to invent any details.++### Goals for unreproduced issues+In May 2020, we decided to draw a line and prioritize issues newer than that date, and gradually work down the remaining backlog over time.++1. for [unreproduced issues reported since May 2020](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+created%3A%3E2020-05-01+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Acreated-asc), we want to keep this number at zero, and have a goal of no issues of older than one month. The issues may not get fixed within a month, but they should either get to a reproducible state or be closed to clear out this queue.++2. For [unreproduced issues reported before May 2020](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+created%3A%3C2020-05-01+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Areactions-%2B1-desc), we want to reduce this number over time. We will roughly prioritize these by upvotes. However, many of the highest-voted issues are also some of the hardest to fix. We strictly prioritize staying on top of new issues.+++### 3. Explain or fix [confirmed issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+)+The next step for confirmed issues is to either:++* explain why the behavior is expected, label the issue as "working as designed", and close it, or+* locate the cause of the defect in the codebase. When the defect is located, and that description is posted on the issue, the issue is labeled "explained". In many cases, this step will get skipped if the fix is obvious, and engineers will jump forward and make a PR. ++#### Goals+Bugs with a high impact with widespread impact should be fixed in the next Z release.++1. All [confirmed crashes](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Acrash+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+) should be fixed in each Z release, even if they are unlikely to have a widespread impact+2. [confirmed non-crash bugs](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+-label%3Adocumentation+-label%3Acrash+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+sort%3Areactions-%2B1-desc) should be resolved roughly in order of upvotes. Most of these issues should be fixed within 4 weeks, and issues that are blocked on needing a larger research or refactor project should have a brief explanation posted and be labeled "pending project"++### 4. The last step for [explained issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+label%3Aexplained+no%3Amilestone+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+) is to make a PR to fix them. ++The issue can be closed and labeled "fixed" after the PR is merged, even if it's not included in a release yet. Since issues can be closed automatically when linked from a PR, labeling them as fixed is not mandatory. This is a convenience to exclude them from these triage filter search results.++Explained issues that are expected to be fixed in a future release should have a milestone++#### Goals+* All explained issues should be fixed or assigned to a future milestone by the time the release candidate of the next major release ships++## GitHub Issue Labels+label                    | description+------------------------ | -----------+new                      | new issue not yet triaged+explained                | a Terraform Core team member has described the root cause of this issue in code+waiting for reproduction | unable to reproduce issue without further information +not reproducible         | closed because a reproduction case could not be generated+duplicate                | issue closed because another issue already tracks this problem+confirmed                | a Terraform Core team member has reproduced this issue+working as designed      | confirmed as reported and closed because the behavior is intended+fixed                    | issue is fixed by PR that has been merged+pending project          | issue is confirmed but will require a significant project to fix++## What is a good reproduction case?++A reproduction case must be something a Terraform Core engineer can git-clone or copy-paste and run immediately, without inventing any details or context. ++### How to write a good reproduction case++* A short example can be directly copy-pasteable; longer examples should be in separate git repositories, especially if multiple files are needed+* Include all needed context. For example, if you figured out that an expression can cause a crash, put the expression in a variable definition or a resource+* Set defaults on (or omit) any needed variables. The person reproducing it should not need to invent variable settings+* If multiple steps are required, such as running terraform twice, consider scripting it in a simple shell script. For example, see [this case](https://github.com/danieldreier/terraform-issue-reproductions/tree/master/25719). Providing a script can be easier than explaining what changes to make to the config between runs.+* Omit any unneeded complexity: remove variables, conditional statements, functions, modules, providers, and resources that are not needed to trigger the bug+* When possible, use the [null resource](https://www.terraform.io/docs/providers/null/resource.html) provider rather than a real provider in order to minimize external dependencies. We know this isn't always feasible. The Terraform Core team doesn't have deep domain knowledge in every provider, or access to every cloud platform for reproduction cases.++## Lack of response and unreproducible issues+When bugs that have been [labeled waiting response](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3A%22waiting+for+reproduction%22+label%3Awaiting-response+-label%3Aexplained+sort%3Aupdated-asc) or [labeled "waiting for reproduction"](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+label%3A%22waiting+for+reproduction%22+-label%3Aexplained+sort%3Aupdated-asc+) for more than 30 days, we'll use our best judgement to determine whether it's more helpful to close it or prompt the reporter again. If they again go without a response for 30 days, they can be closed with a polite message explaining why and inviting the person to submit the needed information or reproduction case in the future.++The intent of this process is to get fix the maximum number of bugs in Terraform as quickly as possible, and having un-actionable bug reports makes it harder for Terraform Core team members and community contributors to find bugs they can actually work on.++## Helpful GitHub Filters++[Confirmed needs for documentation fixes](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+label%3Adocumentation++label%3Aconfirmed+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+)++[Confirmed bugs that will require significant projects to fix](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+label%3Aconfirmed+label%3A%22pending+project%22++-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2)+

I think it would be helpful to gather the various other links to issue searches here, as a sort of quick-access dashboard for people working on triage. Perhaps the link text could have numbered steps in the triage process?

danieldreier

comment created time in 6 days

Pull request review commenthashicorp/terraform

Add bug triage guide

+# Terraform Core GitHub Bug Triage & Labeling+The Terraform Core team has adopted a more structured bug triage process than we previously used. Our goal is to respond to reports of issues quickly.++## Goal+We see working on Terraform as a collaborative process with the community of users. When people find bugs, or run into trouble using Terraform, we want to help.++When a bug report is filed, our goal is to either:+1. Get it to a state where it is ready for engineering to fix it in an upcoming Terraform release, or +2. Close it explain why, if we can't help++The intent of this process is to resolve issues quickly, either by getting them to a state where engineers can fix them, or by closing them when reproduction and resolution is not possible based on available information. +++## Process++### 1. [Newly created issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Anew+label%3Abug+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3A%22waiting+for+reproduction%22+-label%3A%22waiting-response%22+-label%3Aexplained) require initial filtering. ++**Goal**: Most issues triaged within a few days, and no issues should stay in this state for more than 7 days++These are raw reports that need categorization and support clarifying them. They need the following done:++* label backends, provisioners, providers so we can appropriately route work on codebases we don't support to the correct teams+* point requests for help to the community forum and close the issue+* close reports against 0.11+* prompt users who have submitted obviously incomplete reproduction cases for additional information+* If an issue requires discussion with the user to get it out of this initial state, leave "new" on there and label it "waiting-response" until this phase of triage is done.++Once this initial filtering has been done, remove the new label. If an issue subjectively looks very high-impact and likely to impact many users, add it to the [0.13.x milestone](https://github.com/hashicorp/terraform/milestone/17) to mark it as being urgent. ++### 2. Prompt reproduction cases for unreproduced issues++Many bug reports, as originally reported, describe valid issues, but are not detailed enough for engineers to fix. At this stage, we work with people who report bugs to generate clear reproduction cases. ++A core team member initially determines whether the issue is immediately reproducible. If they cannot readily reproduce it, they label it "waiting for reproduction" and correspond with the reporter to describe what is needed. When the issue is reproduced by a core team member, they label it "confirmed". ++"confirmed" issues should have a clear reproduction case, not just be one-off reproduced by someone on the team. Anyone who picks it up should be able to reproduce it readily without having to invent any details.++### Goals for unreproduced issues+In May 2020, we decided to draw a line and prioritize issues newer than that date, and gradually work down the remaining backlog over time.++1. for [unreproduced issues reported since May 2020](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+created%3A%3E2020-05-01+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Acreated-asc), we want to keep this number at zero, and have a goal of no issues of older than one month. The issues may not get fixed within a month, but they should either get to a reproducible state or be closed to clear out this queue.++2. For [unreproduced issues reported before May 2020](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+created%3A%3C2020-05-01+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Areactions-%2B1-desc), we want to reduce this number over time. We will roughly prioritize these by upvotes. However, many of the highest-voted issues are also some of the hardest to fix. We strictly prioritize staying on top of new issues.+++### 3. Explain or fix [confirmed issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+)+The next step for confirmed issues is to either:++* explain why the behavior is expected, label the issue as "working as designed", and close it, or+* locate the cause of the defect in the codebase. When the defect is located, and that description is posted on the issue, the issue is labeled "explained". In many cases, this step will get skipped if the fix is obvious, and engineers will jump forward and make a PR. ++#### Goals+Bugs with a high impact with widespread impact should be fixed in the next Z release.++1. All [confirmed crashes](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Acrash+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+) should be fixed in each Z release, even if they are unlikely to have a widespread impact+2. [confirmed non-crash bugs](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+-label%3Adocumentation+-label%3Acrash+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+sort%3Areactions-%2B1-desc) should be resolved roughly in order of upvotes. Most of these issues should be fixed within 4 weeks, and issues that are blocked on needing a larger research or refactor project should have a brief explanation posted and be labeled "pending project"++### 4. The last step for [explained issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+label%3Aexplained+no%3Amilestone+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+) is to make a PR to fix them. ++The issue can be closed and labeled "fixed" after the PR is merged, even if it's not included in a release yet. Since issues can be closed automatically when linked from a PR, labeling them as fixed is not mandatory. This is a convenience to exclude them from these triage filter search results.++Explained issues that are expected to be fixed in a future release should have a milestone
Explained issues that are expected to be fixed in a future release should be assigned to a milestone.
danieldreier

comment created time in 6 days

Pull request review commenthashicorp/terraform

Add bug triage guide

+# Terraform Core GitHub Bug Triage & Labeling+The Terraform Core team has adopted a more structured bug triage process than we previously used. Our goal is to respond to reports of issues quickly.++## Goal+We see working on Terraform as a collaborative process with the community of users. When people find bugs, or run into trouble using Terraform, we want to help.++When a bug report is filed, our goal is to either:+1. Get it to a state where it is ready for engineering to fix it in an upcoming Terraform release, or +2. Close it explain why, if we can't help++The intent of this process is to resolve issues quickly, either by getting them to a state where engineers can fix them, or by closing them when reproduction and resolution is not possible based on available information. +++## Process++### 1. [Newly created issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Anew+label%3Abug+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3A%22waiting+for+reproduction%22+-label%3A%22waiting-response%22+-label%3Aexplained) require initial filtering. ++**Goal**: Most issues triaged within a few days, and no issues should stay in this state for more than 7 days++These are raw reports that need categorization and support clarifying them. They need the following done:++* label backends, provisioners, providers so we can appropriately route work on codebases we don't support to the correct teams+* point requests for help to the community forum and close the issue+* close reports against 0.11+* prompt users who have submitted obviously incomplete reproduction cases for additional information+* If an issue requires discussion with the user to get it out of this initial state, leave "new" on there and label it "waiting-response" until this phase of triage is done.++Once this initial filtering has been done, remove the new label. If an issue subjectively looks very high-impact and likely to impact many users, add it to the [0.13.x milestone](https://github.com/hashicorp/terraform/milestone/17) to mark it as being urgent. ++### 2. Prompt reproduction cases for unreproduced issues++Many bug reports, as originally reported, describe valid issues, but are not detailed enough for engineers to fix. At this stage, we work with people who report bugs to generate clear reproduction cases. ++A core team member initially determines whether the issue is immediately reproducible. If they cannot readily reproduce it, they label it "waiting for reproduction" and correspond with the reporter to describe what is needed. When the issue is reproduced by a core team member, they label it "confirmed". ++"confirmed" issues should have a clear reproduction case, not just be one-off reproduced by someone on the team. Anyone who picks it up should be able to reproduce it readily without having to invent any details.++### Goals for unreproduced issues+In May 2020, we decided to draw a line and prioritize issues newer than that date, and gradually work down the remaining backlog over time.++1. for [unreproduced issues reported since May 2020](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+created%3A%3E2020-05-01+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Acreated-asc), we want to keep this number at zero, and have a goal of no issues of older than one month. The issues may not get fixed within a month, but they should either get to a reproducible state or be closed to clear out this queue.++2. For [unreproduced issues reported before May 2020](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+created%3A%3C2020-05-01+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Areactions-%2B1-desc), we want to reduce this number over time. We will roughly prioritize these by upvotes. However, many of the highest-voted issues are also some of the hardest to fix. We strictly prioritize staying on top of new issues.+++### 3. Explain or fix [confirmed issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+)+The next step for confirmed issues is to either:++* explain why the behavior is expected, label the issue as "working as designed", and close it, or+* locate the cause of the defect in the codebase. When the defect is located, and that description is posted on the issue, the issue is labeled "explained". In many cases, this step will get skipped if the fix is obvious, and engineers will jump forward and make a PR. ++#### Goals+Bugs with a high impact with widespread impact should be fixed in the next Z release.

I think the "Z release" term might be less clear than "patch release". Alternatively, an example version might help.

danieldreier

comment created time in 6 days

Pull request review commenthashicorp/terraform

Add bug triage guide

+# Terraform Core GitHub Bug Triage & Labeling+The Terraform Core team has adopted a more structured bug triage process than we previously used. Our goal is to respond to reports of issues quickly.++## Goal+We see working on Terraform as a collaborative process with the community of users. When people find bugs, or run into trouble using Terraform, we want to help.++When a bug report is filed, our goal is to either:+1. Get it to a state where it is ready for engineering to fix it in an upcoming Terraform release, or +2. Close it explain why, if we can't help++The intent of this process is to resolve issues quickly, either by getting them to a state where engineers can fix them, or by closing them when reproduction and resolution is not possible based on available information. +++## Process++### 1. [Newly created issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Anew+label%3Abug+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3A%22waiting+for+reproduction%22+-label%3A%22waiting-response%22+-label%3Aexplained) require initial filtering. ++**Goal**: Most issues triaged within a few days, and no issues should stay in this state for more than 7 days++These are raw reports that need categorization and support clarifying them. They need the following done:++* label backends, provisioners, providers so we can appropriately route work on codebases we don't support to the correct teams+* point requests for help to the community forum and close the issue+* close reports against 0.11+* prompt users who have submitted obviously incomplete reproduction cases for additional information+* If an issue requires discussion with the user to get it out of this initial state, leave "new" on there and label it "waiting-response" until this phase of triage is done.++Once this initial filtering has been done, remove the new label. If an issue subjectively looks very high-impact and likely to impact many users, add it to the [0.13.x milestone](https://github.com/hashicorp/terraform/milestone/17) to mark it as being urgent. 

To make this slightly less specific and more evergreen, perhaps something like:

add it to the appropriate milestone to mark it as being urgent.

danieldreier

comment created time in 6 days

Pull request review commenthashicorp/terraform

Add bug triage guide

+# Terraform Core GitHub Bug Triage & Labeling+The Terraform Core team has adopted a more structured bug triage process than we previously used. Our goal is to respond to reports of issues quickly.++## Goal+We see working on Terraform as a collaborative process with the community of users. When people find bugs, or run into trouble using Terraform, we want to help.++When a bug report is filed, our goal is to either:+1. Get it to a state where it is ready for engineering to fix it in an upcoming Terraform release, or +2. Close it explain why, if we can't help++The intent of this process is to resolve issues quickly, either by getting them to a state where engineers can fix them, or by closing them when reproduction and resolution is not possible based on available information. +++## Process++### 1. [Newly created issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Anew+label%3Abug+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3A%22waiting+for+reproduction%22+-label%3A%22waiting-response%22+-label%3Aexplained) require initial filtering. ++**Goal**: Most issues triaged within a few days, and no issues should stay in this state for more than 7 days++These are raw reports that need categorization and support clarifying them. They need the following done:++* label backends, provisioners, providers so we can appropriately route work on codebases we don't support to the correct teams+* point requests for help to the community forum and close the issue+* close reports against 0.11+* prompt users who have submitted obviously incomplete reproduction cases for additional information+* If an issue requires discussion with the user to get it out of this initial state, leave "new" on there and label it "waiting-response" until this phase of triage is done.++Once this initial filtering has been done, remove the new label. If an issue subjectively looks very high-impact and likely to impact many users, add it to the [0.13.x milestone](https://github.com/hashicorp/terraform/milestone/17) to mark it as being urgent. ++### 2. Prompt reproduction cases for unreproduced issues++Many bug reports, as originally reported, describe valid issues, but are not detailed enough for engineers to fix. At this stage, we work with people who report bugs to generate clear reproduction cases. ++A core team member initially determines whether the issue is immediately reproducible. If they cannot readily reproduce it, they label it "waiting for reproduction" and correspond with the reporter to describe what is needed. When the issue is reproduced by a core team member, they label it "confirmed". ++"confirmed" issues should have a clear reproduction case, not just be one-off reproduced by someone on the team. Anyone who picks it up should be able to reproduce it readily without having to invent any details.++### Goals for unreproduced issues+In May 2020, we decided to draw a line and prioritize issues newer than that date, and gradually work down the remaining backlog over time.++1. for [unreproduced issues reported since May 2020](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+created%3A%3E2020-05-01+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Acreated-asc), we want to keep this number at zero, and have a goal of no issues of older than one month. The issues may not get fixed within a month, but they should either get to a reproducible state or be closed to clear out this queue.++2. For [unreproduced issues reported before May 2020](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+created%3A%3C2020-05-01+-label%3Aprovisioner%2Fsalt-masterless+-label%3Adocumentation+-label%3Aprovider%2Fazuredevops+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+-label%3Aconfirmed+-label%3A%22pending+project%22+-label%3Anew+-label%3A%22waiting+for+reproduction%22+-label%3Awaiting-response+-label%3Aexplained+sort%3Areactions-%2B1-desc), we want to reduce this number over time. We will roughly prioritize these by upvotes. However, many of the highest-voted issues are also some of the hardest to fix. We strictly prioritize staying on top of new issues.+++### 3. Explain or fix [confirmed issues](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+)+The next step for confirmed issues is to either:++* explain why the behavior is expected, label the issue as "working as designed", and close it, or+* locate the cause of the defect in the codebase. When the defect is located, and that description is posted on the issue, the issue is labeled "explained". In many cases, this step will get skipped if the fix is obvious, and engineers will jump forward and make a PR. ++#### Goals+Bugs with a high impact with widespread impact should be fixed in the next Z release.++1. All [confirmed crashes](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+label%3Acrash+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent++-label%3Abackend%2Fmanta++-label%3Abackend%2Fatlas++-label%3Abackend%2Fetcdv3++-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+) should be fixed in each Z release, even if they are unlikely to have a widespread impact+2. [confirmed non-crash bugs](https://github.com/hashicorp/terraform/issues?q=is%3Aopen+-label%3Adocumentation+-label%3Acrash+label%3Abug+-label%3Aexplained+-label%3Abackend%2Foss+-label%3Abackend%2Fazure+-label%3Abackend%2Fs3+-label%3Abackend%2Fgcs+-label%3Abackend%2Fconsul+-label%3Abackend%2Fartifactory+-label%3Aterraform-cloud+-label%3Abackend%2Fremote+-label%3Abackend%2Fswift+-label%3Abackend%2Fpg+-label%3Abackend%2Ftencent+-label%3Abackend%2Fmanta+-label%3Abackend%2Fatlas+-label%3Abackend%2Fetcdv3+-label%3Abackend%2Fetcdv2+label%3Aconfirmed+-label%3A%22pending+project%22+sort%3Areactions-%2B1-desc) should be resolved roughly in order of upvotes. Most of these issues should be fixed within 4 weeks, and issues that are blocked on needing a larger research or refactor project should have a brief explanation posted and be labeled "pending project"+

I think there's something to be said here about bug recency and back porting, but I'm not sure what exactly to say. My understanding:

  • Bugs related to recently-released work which have high impact should be fixed in a patch release where possible.
  • Bugs which have existed for longer than the most recent major release are normally by definition less urgent, and do not normally warrant backporting to the stable branch and a patch release. Most commonly these will be released as part of the upcoming major release cycle. Exceptions may be made if the bug is somehow higher impact and a backport is feasible.
danieldreier

comment created time in 6 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
more