The reconfigure flag will force init to ignore any saved backend state.
This is useful when a user does not want any backend migration to
happen, or if the saved configuration can't be loaded at all for some
reason.
Fixes: #13805
Before the fix:
```
Error refreshing state: 1 error(s) occurred:
* logentries_logset.logset: logentries_logset.logset: No such log set with key 278e7344-1201-43ba-9804-77b9a72fe7d6
```
After the fix:
```
% terraform plan ✚ ✭
[WARN] /Users/stacko/Code/go/bin/terraform-provider-logentries overrides an internal plugin for logentries-provider.
If you did not expect to see this message you will need to remove the old plugin.
See https://www.terraform.io/docs/internals/internal-plugins.html
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.
logentries_logset.logset: Refreshing state... (ID: 278e7344-...a72fe7d6)
logentries_log.log: Refreshing state... (ID: 2ae1e8ae-...e932d25c)
The Terraform execution plan has been generated and is shown below.
Resources are shown in alphabetical order for quick scanning. Green resources
will be created (or destroyed and then created if an existing resource
exists), yellow resources are being changed in-place, and red resources
will be destroyed. Cyan entries are data sources to be read.
Note: You didn't specify an "-out" parameter to save this plan, so when
"apply" is called, Terraform can't guarantee this is what will execute.
+ logentries_log.log
logset_id: "${logentries_logset.logset.id}"
name: "test-log"
retention_period: "ACCOUNT_DEFAULT"
source: "token"
token: "<computed>"
+ logentries_logset.logset
location: "nonlocation"
name: "testing-terraform-destroy"
Plan: 2 to add, 0 to change, 0 to destroy.
```
Test Run:
```
% make testacc TEST=./builtin/providers/logentries ✚ ✭
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/04/20 20:36:20 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/logentries -v -timeout 120m
=== RUN TestProvider
--- PASS: TestProvider (0.00s)
=== RUN TestProvider_impl
--- PASS: TestProvider_impl (0.00s)
=== RUN TestAccLogentriesLog_Token
--- PASS: TestAccLogentriesLog_Token (39.03s)
=== RUN TestAccLogentriesLog_SourceApi
--- PASS: TestAccLogentriesLog_SourceApi (28.46s)
=== RUN TestAccLogentriesLog_SourceAgent
--- PASS: TestAccLogentriesLog_SourceAgent (6.19s)
=== RUN TestAccLogentriesLog_RetentionPeriod1M
--- PASS: TestAccLogentriesLog_RetentionPeriod1M (3.04s)
=== RUN TestAccLogentriesLog_RetentionPeriodAccountDefault
--- PASS: TestAccLogentriesLog_RetentionPeriodAccountDefault (2.71s)
=== RUN TestAccLogentriesLog_RetentionPeriodAccountUnlimited
--- PASS: TestAccLogentriesLog_RetentionPeriodAccountUnlimited (2.65s)
=== RUN TestAccLogentriesLogSet_Basic
--- PASS: TestAccLogentriesLogSet_Basic (1.54s)
=== RUN TestAccLogentriesLogSet_NoLocation
--- PASS: TestAccLogentriesLogSet_NoLocation (1.54s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/logentries 85.177s
```
A couple tests require lowering the grace period to keep the test from
taking the full 30s timeout.
The Retry_hang test also needed to be removed from the Parallel group,
becuase it modifies the global refreshGracePeriod variable.
Refresh calls may have side effects that need to be recorded if it
succeeds, especially common when when WaitForState is called from
resource.Retry.
If the WaitForState timeout is reached and there is a Refresh call
in-flight, wait up to refreshGracePeriod (set to 30s) for it to
complete.
Previously we fixed this specifically for the Enterprise VCS integration,
but we also had some long-running errors of this sort in the docs for
how to specify module sources on Bitbucket.
=