Commit Graph

28490 Commits

Author SHA1 Message Date
Alisdair McDiarmid a740b739e0 command: Change 0.13upgrade default to versions.tf
Instead of using providers.tf as the default output file for the
upgrader, we now default to versions.tf. This means that if the
configuration has no `required_providers` blocks at all, or has
multiple, the provider version requirements will be stored in the
versions.tf file.

We now also update the versions.tf file to set a `required_version`
attribute in the first `terraform` block, with value ">= 0.13". This
is similar to the behaviour of the 0.12upgrade command, and signals that
the configuration should not be used with older versions of Terraform.
2020-05-07 15:45:48 -04:00
Alisdair McDiarmid 01a3376ead command: Check required_version before upgrading
If a configuration has a version constraint which prevents use with
Terraform 0.13, the upgrade command should exit before making any
changes.
2020-05-07 15:45:48 -04:00
Martin Atkins 7209ffe9b6
Update CHANGELOG.md 2020-05-07 11:10:57 -07:00
Martin Atkins f897863288 providers/terraform: test that validation does not configure backend 2020-05-07 11:08:10 -07:00
Ben Drucker db1a623ed4 backend/terraform: additional test coverage for error cases in getBackend 2020-05-07 11:08:10 -07:00
Ben Drucker 81b8891b90 providers/terraform: don't call backend.Configure to validate terraform_remote_state
Validation is supposed to be a local-only operation, but Configure implementations
are allowed to make outgoing requests to remote APIs to validate settings.
2020-05-07 11:08:10 -07:00
Alisdair McDiarmid de541c4d74
Merge pull request #24879 from hashicorp/alisdair/013upgrade-rework
command: Rework 0.13upgrade sub-command
2020-05-07 12:00:42 -04:00
Alisdair McDiarmid ae98bd12a7 command: Rework 0.13upgrade sub-command
This commit implements most of the intended functionality of the upgrade
command for rewriting configurations.

For a given module, it makes a list of all providers in use. Then it
attempts to detect the source address for providers without an explicit
source.

Once this step is complete, the tool rewrites the relevant configuration
files. This results in a single "required_providers" block for the
module, with a source for each provider.

Any providers for which the source cannot be detected (for example,
unofficial providers) will need a source to be defined by the user. The
tool writes an explanatory comment to the configuration to help with
this.
2020-05-07 11:38:55 -04:00
Alisdair McDiarmid 5b307a07dc vendor: go get github.com/hashicorp/hcl/v2@v2.5.0 2020-05-07 10:35:08 -04:00
Pam Selle e186264439
Update CHANGELOG.md 2020-05-06 15:25:20 -04:00
Pam Selle 60b3815af4
Merge pull request #24696 from hashicorp/leetrout/remote-state-force-push
Add support for force pushing with the remote backend
2020-05-06 15:23:28 -04:00
Lee Trout cb0e20ca2b Add support for force pushing with the remote backend
Both differing serials and lineage protections should be bypassed
with the -force flag (in addition to resources).

Compared to other backends we aren’t just shipping over the state
bytes in a simple payload during the persistence phase of the push
command and the force flag added to the Go TFE client needs to be
specified at that time.

To prevent changing every method signature of PersistState of the
remote client I added an optional interface that provides a hook
to flag the Client as operating in a force push context. Changing
the method signature would be more explicit at the cost of not
being used anywhere else currently or the optional interface pattern
could be applied to the state itself so it could be upgraded to
support PersistState(force bool) only when needed.

Prior to this only the resources of the state were checked for
changes not the lineage or the serial. To bring this in line with
documented behavior noted above those attributes also have a “read”
counterpart just like state has. These are now checked along with
state to determine if the state as a whole is unchanged.

Tests were altered to table driven test format and testing was
expanded to include WriteStateForMigration and its interaction
with a ClientForcePusher type.
2020-05-06 12:07:43 -04:00
Pam Selle 3e420d5f6d
Merge pull request #24874 from hashicorp/pselle/modulecallexpansionvalidation
Add more validation to expanding modules
2020-05-06 10:12:14 -04:00
Pam Selle 38e5d9c699 Add more validation to expanding modules 2020-05-06 09:52:11 -04:00
Chris Griggs 3c1854c206 Adding community provider 2020-05-05 14:35:02 -07:00
James Bardin e48c5d3d82 update CHANGELOG.md 2020-05-05 17:19:41 -04:00
Sander van Harmelen 2e5fbdf684 Remove (now) incorrect example
This example doesn't really show how these values should be used. The
default of retry_on_exit_code is now already when most people want, so
this line is not needed in most cases.

I think the docs describe the new options just fine, so lets leave this
out...
2020-05-05 16:31:57 -04:00
Sander van Harmelen 9453308c78 Make sure the WinRM communicator can reconnect 2020-05-05 16:18:30 -04:00
Sander van Harmelen 10aab86051 Make sure we use MaxRetries correctly
Even if MaxRetries is 0, we should still execute the loop one time in
order to run the Chef-Client at least once. Also waiting only makes
sense when we have `attempts` left. And last but not least we want to
exit immediately when the exit code is not in the retry list.

So this PR fixes three small issues to make everything work as
expected.
2020-05-05 16:18:30 -04:00
Martin Atkins 0e9e9243dd
Update CHANGELOG.md 2020-05-05 10:00:07 -07:00
Mike Morris 9568de6b90
command: Fix OAuth2 PKCE arguments
Providers like Okta and AWS Cognito expect that the PKCE challenge
uses base64 URL Encoding without any padding (base64.RawURLEncoding)

Additionally, Okta strictly adheres to section 4.2 of RFC 7636 and
requires that the unencoded key for the PKCE data is at least 43
characters in length.
2020-05-05 09:58:48 -07:00
Kristin Laemmert 0b76100da0
init: return proper config errors (#24865)
Fixed a bug where we were returning earlyConfDiags instead of confDiags.
2020-05-05 10:08:05 -04:00
Daniel Dreier 0749e419de
Merge pull request #24484 from ctjhoa/fix_typo
fix typo in Base64DecodeFunc log
2020-05-04 16:11:47 -07:00
Daniel Dreier dec1244852
Merge pull request #24843 from kuritonasu/master
Fixed minor grammatical errors
2020-05-04 15:57:59 -07:00
Alex Pilon f1030826ba skip lock comments on issues closed/updated over 60 days
remove cherry pick labeler, we won't be doing that anymore
2020-05-04 17:59:03 -04:00
Lee Trout c2c38b2ad3 Add remote state test for serial and lineage changes
We only persist a new state if the actual state contents have
changed. This test demonstrates that behavior by calling write
and persist methods when either the lineage or serial have changed.
2020-05-04 11:48:50 -04:00
Kritonas 71395a0656 Fixed minor grammatical errors 2020-05-04 17:34:50 +03:00
James Bardin 9debd341bc
Merge pull request #24807 from hashicorp/jbardin/remove-each-mode
Remove EachMode from state
2020-05-03 10:54:07 -04:00
Sander van Harmelen a614056925 Refactor the code a bit to make it more idiomatic 2020-05-01 08:58:33 -04:00
Kristin Laemmert cca0526705
providercache: actually break out of the loop when a matching version is found (#24823) 2020-05-01 08:49:47 -04:00
Kristin Laemmert ce03f1255f
internal/providercache: fix error message for protocol mismatch (#24818)
There was a bug in the installer trying to pass a nil error.
2020-04-30 11:12:04 -04:00
James Bardin 2bfaddcf57 fix state mv to work without EachMode
The only situation where `state mv` needs to understand the each mode is
when with resource addresses that may reference a single instance, or a
group of for_each or count instances. In this case we can differentiate
the two by checking the existence of the NoKey instance key.
2020-04-30 09:22:15 -04:00
James Bardin 15a95031e5 remove a few traces of states.EachMode 2020-04-30 09:22:15 -04:00
James Bardin 98cf28b02d 2 more tests that weren't correct
Found 2 more tests that still had dangling empty modules, which are now
fixed.
2020-04-30 09:22:14 -04:00
James Bardin f915c5d957 remove EachMode from resource state
Due to the fact that resources can transition between each modes, trying
to track the mode for a resource as a whole in state doesn't work,
because there may be instances with a mode different from the resource
as a whole. This is difficult for core to track, as this metadata being
changed as a side effect from multiple places often causes core to see
the incorrect mode when evaluating instances.

Since core can always determine the correct mode to evaluate from the
configuration, we don't need to interrogate the state to know the mode.
Once core no longer needs to reference EachMode from states, the
resource state can simply be a container for instances, and doesn't need
to try and track the "current" mode.
2020-04-30 09:22:14 -04:00
Pam Selle 87bce5f9dd
Support reading module outputs in terraform console (#24808)
* Include eval in output walk

This allows outputs to be evaluated in the evalwalk,
impacting terraform console. Outputs are still not evaluated
for terraform console in the root module, so this has
no impact on writing to state (as child module outputs are not
written to state). Also adds test coverage to the console command,
including for evaluating locals (another use of the evalwalk)
2020-04-30 09:21:42 -04:00
James Bardin 67f66ee970
Merge pull request #24751 from hashicorp/jbardin/mod-resource-evaluation
Resource (and module) evaluate improvements
2020-04-30 09:21:15 -04:00
Brian Dwyer 2f4067cf70
Clean up and add docs
Signed-off-by: Brian Dwyer <Brian.Dwyer@broadridge.com>
2020-04-30 08:16:17 -04:00
Brian Dwyer 4701ed2e02
Gracefully handle Chef RFC062 Exit Codes
Signed-off-by: Brian Dwyer <Brian.Dwyer@broadridge.com>
2020-04-29 23:48:19 -04:00
Alisdair McDiarmid 43030b21ac
Merge pull request #24783 from hashicorp/alisdair/implied-provider-lookup-by-localname
configs: Fix for resources with implied providers
2020-04-28 15:15:47 -04:00
Alisdair McDiarmid dcb8b45e0f configs: Fix for resources with implied providers
Previously, resources without explicit provider configuration (i.e. a
`provider =` attribute) would be assigned a default provider based upon
the resource type. For example, a resource `foo_bar` would be assigned
provider `hashicorp/foo`.

This behaviour did not work well with community or partner providers,
with sources configured in `terraform.required_providers` blocks. With
the following configuration:

    terraform {
      required_providers {
        foo = {
          source = "acme/foo"
        }
      }
    }

    resource foo_bar "a" { }

the resource would be configured with the `hashicorp/foo` provider.

This commit fixes this implied provider behaviour. First we look for a
provider with local name matching the resource type in the module's
required providers map. If one is found, this provider is assigned to
the resource. Otherwise, we still fall back to a default provider.
2020-04-28 14:54:31 -04:00
Robin Norwood d47f984e75
Add reference to new modules track (#24445) 2020-04-28 11:09:42 -07:00
Pam Selle 9957a6b42b
Update CHANGELOG.md 2020-04-28 12:27:10 -04:00
Daniel Dreier c5a2e27003
Merge pull request #24786 from hashicorp/danieldreier-23510-changelog
Update CHANGELOG.md for swift authentication
2020-04-28 09:04:16 -07:00
kmoe 8e7a4a6c21
Merge pull request #24670 from hashicorp/kmoe-cloudinit-provider
Cloud-init provider link
2020-04-28 10:03:46 +01:00
Daniel Dreier cc3c18ac35
Update CHANGELOG.md for swift authentication 2020-04-27 14:48:33 -07:00
Daniel Dreier 1170efb14a
Merge pull request #23510 from kayrus/new-swift-opts
backend/remote: Swift Authentication Update
2020-04-27 14:37:25 -07:00
Pam Selle 5956276590
Merge pull request #24780 from hashicorp/pselle/walkEval
Add expansion transformer to eval graph
2020-04-27 15:39:15 -04:00
Daniel Dreier 7aa97f415d
Fix "additoinal" typo in web site
Fixes 24769
2020-04-27 10:14:27 -07:00
Pam Selle 6ee42efe16 Add expansion transformer to eval graph
Add the expansion transformer to the eval graph,
which is used in rare scenarios which includes running
terraform console. Prevents panic when running terraform
console in contexts with module expansion
2020-04-27 13:09:08 -04:00