Always install the latest plugin versions for Terraform tests

[hakman]

/cc @rifelpet

[hakman]

/test pull-kops-verify-terraform

[rifelpet]

will this mean we no longer catch situations where we use a recently-added field for a terraform resource but forget to update the minimum provider version to match?

kops/upup/pkg/fi/cloudup/terraform/target_hcl2.go

Lines 102 to 117 in c3cd96b

	if t.Cloud.ProviderID() == kops.CloudProviderGCE {
	writeMap(requiredProvidersBody, "google", map[string]cty.Value{
	"source": cty.StringVal("hashicorp/google"),
	"version": cty.StringVal(">= 2.19.0"),
	})
	} else if t.Cloud.ProviderID() == kops.CloudProviderAWS {
	writeMap(requiredProvidersBody, "aws", map[string]cty.Value{
	"source": cty.StringVal("hashicorp/aws"),
	"version": cty.StringVal(">= 3.34.0"),
	})
	if featureflag.Spotinst.Enabled() {
	writeMap(requiredProvidersBody, "spotinst", map[string]cty.Value{
	"source": cty.StringVal("spotinst/spotinst"),
	"version": cty.StringVal(">= 1.33.0"),
	})
	}

[hakman]

Should still respect the constraints, but upgrade the plugins cached on dev machines to latest allowed.

  -upgrade=false       If installing modules (-get) or plugins, ignore
                       previously-downloaded objects and install the
                       latest version allowed within configured constraints.

[johngmyers]

Should we have the tests always specify the lowest provider versions?

[johngmyers]

Test twice, once with oldest and once with newest?

[hakman]

This is how I noticed that it doesn't work. It failed all tests for me this morning because the AWS provider was too old locally and it didn't what to do. Had to add this change to work.
Yes, I tested and respects the constraints for minimum provider version.

[hakman]

/retest

[rifelpet]

I'm not sure I understand why it would have failed for you. If you had a version < 3.34.0 cached locally, I would expect terraform init (no -upgrade) to redownload the provider >= 3.34.0 rather than trying to use a version that doesn't match the defined requirements. If 3.34.0 isn't actually sufficient to use all of the functionality that we generate, then we should bump the minimum version.

I do like the idea of testing twice, once with the oldest and once with the newest. I'm not sure how easily we can do that though, it might require editing the required_providers block to use = instead of >=

[hakman]

This is how it behaves for me:

> terraform init

Initializing the backend...

Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file

Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider hashicorp/aws:
locked provider registry.terraform.io/hashicorp/aws 3.31.0 does not match
configured version constraint >= 3.34.0; must use terraform init -upgrade to
allow selection of new versions

[rifelpet]

ah, that makes (a bit) more sense. does terraform init -upgrade then download 3.34.0 or the latest 3.X ?

[hakman]

Yup :)
If you use "= 3.30.0", it will download 3.30.0 when using -upgrade.

[rifelpet]

but using >= 3.34.0 will download the latest 3.X ?

[hakman]

Yes, will download the latest 3.X, but it's the same as what the automated test does.

hakman@MecTroll minimal-ipv6 % terraform init -upgrade

Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/aws versions matching ">= 3.32.0"...
- Installing hashicorp/aws v3.39.0...
- Installed hashicorp/aws v3.39.0 (self-signed, key ID 34365D9472D7468F)

[rifelpet]

you're right that this preserves the existing functionality of the prow job so I'm inclined to merge as-is and if we can add more testing in a separate PR with = instead of >= that would be ideal.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rifelpet

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [rifelpet]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment