e34be68633
Added exit command mention
2016-11-17 04:23:50 -05:00
81125f6aeb
Update CHANGELOG.md
2016-11-16 13:45:29 -06:00
d004a24659
Merge pull request #10171 from Ninir/vpc_enable_dns_support
...
provider/aws: Fixed the aws_vpc enable_dns_support handling on creation
2016-11-16 13:41:35 -06:00
50ecb746ec
Merge pull request #10170 from hashicorp/jbardin/no-darwin-386
...
Remove darwin/386 from the build
2016-11-16 14:06:33 -05:00
281eba72ad
provider/aws: Fixed the aws_vpc enable_dns_support handling on creation
2016-11-16 20:05:49 +01:00
f85232a239
Remove darwin/386 from the build
...
There isn't a supported configuration that runs darwin/386, so remove it
from the build.
2016-11-16 13:46:57 -05:00
789b660b32
Update CHANGELOG.md
2016-11-16 19:19:17 +02:00
06b95b3c00
release: clean up after v0.8.0-beta2
2016-11-16 17:14:31 +00:00
7e4385ea2f
v0.8.0-beta2
2016-11-16 17:13:31 +00:00
e319d2cd59
Merge pull request #10105 from hashicorp/f-chef-key_material
...
provider/chef: Migrate Chef to use KEY_MATERIAL rather than using a Pem file
2016-11-16 19:12:28 +02:00
50cab912af
provider/chef: Migrate Chef to use KEY_MATERIAL rather than using a Pem
...
file
This will allow us to standardise on how we set KEY_MATERIAL
2016-11-16 19:03:37 +02:00
7293630f64
Merge pull request #10140 from jjasghar/patch-1
...
Update index.html.markdown
2016-11-16 09:22:30 +02:00
7aab812750
Merge pull request #10145 from jrnt30/explicit-elb-defaults
...
Doc Update for ELB defaults
2016-11-16 09:19:35 +02:00
db49d52889
update CHANGELOG
2016-11-15 15:36:09 -08:00
20e3ae3aa7
Merge pull request #10150 from hashicorp/update-hil
...
vendor: update HIL
2016-11-15 15:32:38 -08:00
8fab86a9d4
website: update docs for precedence rules
2016-11-15 15:29:38 -08:00
9daa9942b3
vendor: update HIL
2016-11-15 15:24:48 -08:00
ed2fd5ab1f
release: clean up after v0.7.11
2016-11-15 22:26:09 +00:00
75257e13ab
Doc Update for ELB defaults
...
- Doc update to explicitly call out ELB defaults (so I don't have to look
at the source again :)
2016-11-15 15:00:13 -06:00
5eaeb0f89f
Update CHANGELOG.md
2016-11-15 11:56:14 -08:00
ea2c084176
Merge pull request #10141 from hashicorp/revert-9118-spew-diff-mismatch
...
Revert "[WIP] core: Log diff mismatch using spew instead of %#v"
2016-11-15 11:53:37 -08:00
b72ef90c2f
Revert "[WIP] core: Log diff mismatch using spew instead of %#v"
2016-11-15 11:53:28 -08:00
b20f43834b
Merge pull request #9118 from hashicorp/spew-diff-mismatch
...
[WIP] core: Log diff mismatch using spew instead of %#v
2016-11-15 11:53:19 -08:00
97943acbf8
Merge pull request #10139 from hashicorp/b-schema-diff-destroy
...
helper/schema: mark diff as forcenew if element is computed
2016-11-15 11:50:12 -08:00
07c80ef09d
Update index.html.markdown
...
Added a note about self-signed certs and vsphere.
2016-11-15 13:49:01 -06:00
55ef93f0f9
terraform: Diff.Same should understand that Destroy might go false
2016-11-15 11:26:42 -08:00
39542898b0
helper/schema: mark diff as forcenew if element is computed
...
Fixes #10125
If the elements are computed and the field is ForceNew, then we should
mark the computed count as potentially forcing a new operation.
Example, assuming `groups` forces new...
**Step 1:**
groups = ["1", "2", "3"]
At this point, the resource isn't create, so this should result in a
diff like:
CREATE resource:
groups: "" => ["1", "2", "3"]
**Step 2:**
groups = ["${computedvar}"]
The OLD behavior was:
UPDATE resource
groups.#: "3" => "computed"
This would cause a diff mismatch because if `${computedvar}` was
different then it should force new. The NEW behavior is:
DESTROY/CREATE resource:
groups.#: "3" => "computed" (forces new)
2016-11-15 11:02:14 -08:00
75aabd7a79
Merge pull request #10118 from hashicorp/b-config-race
...
config: maintain slice index accounting for computed keys
2016-11-15 09:06:12 -08:00
dc2c4cc417
Merge pull request #10135 from hashicorp/b-data-info
...
terraform: EvalInstanceInfo on data sources in new graph
2016-11-15 09:04:05 -08:00
c6fd938fb8
terraform: EvalInstanceInfo on data sources in new graph
...
This doesn't cause any practical issues as far as I'm aware (couldn't
get any test to fail), but caused shadow errors since it wasn't matching
the prior behavior.
2016-11-15 09:02:10 -08:00
9aef2e5aa8
Update CHANGELOG.md
2016-11-15 11:00:51 -06:00
0369112057
Merge branch 'pr-10113'
...
* pr-10113:
Added retry_option for aws_kinesis_firehose_stream redshift_configuration
2016-11-15 10:56:16 -06:00
3d56d20d82
Added retry_option for aws_kinesis_firehose_stream redshift_configuration
2016-11-15 10:55:02 -06:00
b6f5eb6371
Merge pull request #10134 from hashicorp/b-shadow-close
...
helper/shadow: Close for auto-closing all values
2016-11-15 08:54:42 -08:00
6557a3de18
helper/shadow: Close for auto-closing all values
...
Fixes #10122
The simple fix was that we forgot to close `ReadDataApply` for the
provider. But I've always felt that this section of the code was brittle
and I wanted to put in a more robust solution. The `shadow.Close` method
uses reflection to automatically close all values.
2016-11-15 08:54:26 -08:00
35f3d46a9d
Update CHANGELOG.md
2016-11-15 10:01:02 -06:00
665ca05bf6
Merge pull request #10112 from Ninir/aws_kinesis_firehose_stream_buffer_option
...
provider/aws: kinesis_firehose_delivery_stream: Fixed ES buffering_interval option
2016-11-15 09:55:12 -06:00
4e2865a719
Merge pull request #10131 from jrnt30/increased-db-options-delete
...
GH-7311 - Increasing deletion timeout wait
2016-11-15 09:27:45 -06:00
23de57ddf3
Merge pull request #10104 from hashicorp/jbardin/debug
...
DebugOperation
2016-11-15 10:16:08 -05:00
e36f424af3
GH-7311 - Increasing deletion timeout wait
...
- Per our discussion around the PR to increase this initially, we
weren't sure if 1 minute would be sufficient. Well, it turns out it
wasn't for me today (we don't delete these often so not sure how
often people run into this).
Picking another somewhat arbitrary value of 5 minutes in the hopes
that it will be sufficient (today it took a little over 2 minutes).
2016-11-15 09:11:28 -06:00
68fbbecb3e
Update CHANGELOG.md
2016-11-15 05:04:53 +00:00
9f86127d6b
Merge pull request #10116 from jeremy-asher/increase_aws_lambda_function_timeout
...
increase aws_lambda_function timeout
2016-11-15 05:04:08 +00:00
b33adf10f8
Merge pull request #10110 from paybyphone/pbp_asg_doc_initial_lifecycle
...
docs/aws: Document initial_lifecycle_hook in aws_autoscaling_group
2016-11-15 04:59:09 +00:00
922a39734d
Merge pull request #10119 from hashicorp/b-update-hil
...
vendor: update hil
2016-11-14 19:55:09 -08:00
9afce5aa6e
vendor: update hil
2016-11-14 19:51:43 -08:00
b3f80b9469
config: maintain slice index accounting for computed keys
...
Fixes #10075
Fixes #10013
When interpolating, we were only maintaining the last known slice index.
If you had sibling slices then you could lose your slice index when
exiting the slice. The resulting behavior was that no some runs the
computed key would be: "slice.0.attr" and on others would be
"slice.attr", the latter being incorrect.
We now maintain a list of slice indexes so that as we unnest, we
properly restore the old value.
Surprisingly unrelated to the graph but the shadow graph caught this
which is great. :)
2016-11-14 18:33:29 -08:00
ece6f30a21
increase aws_lambda_function timeout
...
Since the Lambda CreateFunction call may include an up to 50MB payload,
the request can easily take more than a minute. This increases the
timeout to 10 minutes.
2016-11-14 15:50:39 -08:00
e077e4b260
provider/aws: fixed buffering_interval option
2016-11-14 22:18:11 +01:00
051a4227d0
docs/aws: Document initial_lifecycle_hook in aws_autoscaling_group
...
This is a useful feature that seems to have been added in September,
with 7dd7078
2016-11-14 12:06:00 -08:00
7fbd880390
update CHANGELOG
2016-11-14 11:56:25 -08:00
James Turnbull