Commit Graph

25909 Commits

Author SHA1 Message Date
Daniel Dreier c057487997
Merge pull request #24946 from hashicorp/danieldreier/hashibot_config
Remove hashibot panic issue labeler
2020-05-13 18:02:57 -07:00
charlotte.mach 172d6caf04 Add info on dynamodb locking multiple state files as per issue #15303 2020-05-13 15:04:56 -07:00
Daniel Dreier 7aa8e65e16 Remove hashibot panic issue labeler
HashiBot labels issues as "crash" and "bug" when they container "panic:". This causes issues to bypass human triage, which means that provider-specific panics are put in our issue list rather than being labeled correctly. This removes that rule to allow for human labeling.
2020-05-13 11:58:57 -07:00
Kristin Laemmert d350818126
internal/getproviders: fix panic with invalid path parts (#24940)
* internal/getproviders: fix panic with invalid path parts

If the search path is missing a directory, the provider installer would
try to create an addrs.Provider with the wrong parts. For example if the
hostname was missing (as in the test case), it would call
addrs.NewProvider with (namespace, typename, version). This adds a
validation step for each part before calling addrs.NewProvider to avoid
the panic.
2020-05-13 13:16:09 -04:00
Petros Kolyvas 95ad52de11
Merge pull request #24942 from izeau/patch-1
website/docs: provider aliases in the JSON format
2020-05-13 11:59:09 -04:00
Alisdair McDiarmid c3c8fbd4db
Merge pull request #24917 from hashicorp/alisdair/registry-retries
internal/getproviders: Add configurable HTTP retry & timeout support
2020-05-13 10:17:12 -04:00
Jean Dupouy a54bb124a9
website/docs: provider aliases in the JSON format
Fixes #24889
2020-05-13 15:52:26 +02:00
Alisdair McDiarmid 070c3018f8 internal/providercache: Remove unused retry events 2020-05-13 09:48:41 -04:00
Alisdair McDiarmid e27a36cafd internal/getproviders: Retry failed HTTP requests
This is a port of the retry/timeout logic added in #24260 and #24259,
using the same environment variables to configure the retry and timeout
settings.
2020-05-13 09:48:41 -04:00
Alisdair McDiarmid 9a5e5bb5fc
Merge pull request #24841 from rafalpotempa/upgrade-crypto
Security: Upgrade version of golang.org/x/crypto to latest
2020-05-13 09:19:36 -04:00
Rafal Potempa 2646e42ac9 Upgrade version 2020-05-13 09:33:27 +02:00
Rafal Potempa b630543985 Upgrade crypto 2020-05-13 09:31:39 +02:00
James Bardin 6cf3f76623 update CHANGELOG.md 2020-05-12 17:12:41 -04:00
James Bardin e912dc8551
Merge pull request #19155 from bdwyertech/chef-exit-codes
Chef: Gracefully Handle RFC062 Exit Codes
2020-05-12 17:09:05 -04:00
James Bardin 2b9cb0e0e1
Merge pull request #24930 from hashicorp/jbardin/rename-expanders
Rename expanders
2020-05-12 16:16:12 -04:00
James Bardin 07c35dd4df update test strings
Match the new names output by the expander nodes
2020-05-12 11:07:00 -04:00
James Bardin 5cb6c86b32 rename plannable output
NodePlannableOutput is now the expander node, and is used in contexts
other than planning. Change the name to nodeExpandOutput
2020-05-12 11:07:00 -04:00
James Bardin 3a3eaa1ddf rename plannable local
NodePLannableLocal is now the expander node, and is is also used in
contexts other than plan. Change the name to nodeExpandLocal.
2020-05-12 11:07:00 -04:00
James Bardin a2d2ce35dc remove "prepare state" from expanders
That name tag was left in only to reduce the diff when during
implementation. Fix the naming now for these nodes so it is correct, and
prevent any possible name collision between types.
2020-05-12 10:28:33 -04:00
Kristin Laemmert 862dc36884
command/init: include config loader diagnostics in output (#24921)
Previously the diagnostics from the config loaders (earlyconfig and
regular) were only appended to the overall diags if an error was found.
This adds all diagnostics from the regular config loader so that any
generated warnings will be displayed, even if there are no errors.

I did not add the `earlyconfig` warnings since they will be displayed if
there is an error and are likely to be duplicated by the config loader.
2020-05-12 08:39:12 -04:00
Alisdair McDiarmid 14985469b4
Merge pull request #24915 from hashicorp/alisdair/013upgrade-docs
website: Add docs for 0.13upgrade
2020-05-11 15:42:25 -04:00
Alisdair McDiarmid 20483da548 website: Add docs for 0.13upgrade 2020-05-11 15:38:16 -04:00
Kristin Laemmert 60321b41e8
getproviders: move protocol compatibility functions into registry client (#24846)
* internal/registry source: return error if requested provider version protocols are not supported

* getproviders: move responsibility for protocol compatibility checks into the registry client

The original implementation had the providercache checking the provider
metadata for protocol compatibility, but this is only relevant for the
registry source so it made more sense to move the logic into
getproviders.

This also addresses an issue where we were pulling the metadata for
every provider version until we found one that was supported. I've
extended the registry client to unmarshal the protocols in
`ProviderVersions` so we can filter through that list, instead of
pulling each version's metadata.
2020-05-11 13:49:12 -04:00
Alisdair McDiarmid 1d834fb1d0
Merge pull request #24906 from hashicorp/alisdair/013upgrade-confirm
command: Add prompt & confirmation to 0.13upgrade
2020-05-11 12:29:46 -04:00
Alisdair McDiarmid 82ebbf9a23 command: Add prompt & confirmation to 0.13upgrade 2020-05-11 09:32:11 -04:00
Alisdair McDiarmid 47cd97bee2
Merge pull request #24903 from hashicorp/alisdair/lookup-legacy-provider-fix
internal: Fix LookupLegacyProvider
2020-05-11 09:13:16 -04:00
Alisdair McDiarmid 62b0cbed12 internal: Fix LookupLegacyProvider
When looking up the namespace for a legacy provider source, we need to
use the /v1/providers/-/{name}/versions endpoint. For non-HashiCorp
providers, the /v1/providers/-/{name} endpoint returns a 404.

This commit updates the LegacyProviderDefaultNamespace method and the
mock registry servers accordingly.
2020-05-08 12:29:25 -04:00
Pam Selle f82700bc56
Disallow provider configuration in expanding modules (#24892)
Validate providers in expanding modules. Expanding modules cannot have provider configurations with non-empty configs, which includes having a version configured. If an empty or alias-only block is passed, the provider must be passed through the providers argument on the module call
2020-05-08 11:35:28 -04:00
Chris Griggs 53a36a11b2
Merge pull request #24875 from hashicorp/cgriggs01-community
[Website] Adding community providers
2020-05-08 07:59:46 -07:00
Alisdair McDiarmid 0104e63c64
Merge pull request #24894 from hashicorp/alisdair/013upgrade-required-version
command: 0.13upgrade command checks and updates required_version
2020-05-08 08:50:56 -04:00
Alisdair McDiarmid 1fdcbc4825 command: Fix 0.13upgrade bug with multiple blocks
If a configuration had multiple blocks in the versions.tf file, it would
be added to the `rewritePaths` list multiple times. We would then remove
it from this slice, but only once, and so the output file would later be
rewritten to remove the required providers block.

This commit uses a set instead of a list to prevent this case, and adds
a regression test.
2020-05-07 20:11:44 -04:00
Alisdair McDiarmid e2be704d81 command: Extract reused hclwrite helper code 2020-05-07 20:11:44 -04:00
Robin Norwood af5c425360
website: Add link to new learn track in configuration/modules.html (#24847) 2020-05-07 15:52:22 -07:00
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