```
make testacc TEST=./builtin/providers/aws
TESTARGS='-run=TestAccAWSIAMAccountPasswordPolicy_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/aws -v
-run=TestAccAWSIAMAccountPasswordPolicy_ -timeout 120m
=== RUN TestAccAWSIAMAccountPasswordPolicy_importBasic
--- PASS: TestAccAWSIAMAccountPasswordPolicy_importBasic (14.75s)
=== RUN TestAccAWSIAMAccountPasswordPolicy_basic
--- PASS: TestAccAWSIAMAccountPasswordPolicy_basic (26.06s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 40.831s
```
For both the file and virtual_disk resource, Stat is used during read,
but if Stat returns an error, read() will return that error. In doing
so, if a resource is deleted manually, the TF user would then not be
able to destroy the resource because the read would block the Delete()
call. With this patch, read() will only return an error if that error
is NOT a DatastoreNoSuchFileError.
Small change to the test as it was failing sometimes as it was using the
same identifier. The small change has made it more stable when running
it in quick succession as it isn't an update
```
make testacc TEST=./builtin/providers/aws
TESTARGS='-run=TestAccAWSIAMGroup_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSIAMGroup_
-timeout 120m
=== RUN TestAccAWSIAMGroup_importBasic
--- PASS: TestAccAWSIAMGroup_importBasic (14.14s)
=== RUN TestAccAWSIAMGroup_basic
--- PASS: TestAccAWSIAMGroup_basic (22.88s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 37.040s
```
The Id wasn't being set until after the Read func returned from the API.
I needed to move that Id set up until just after the Create response
returned
The same Id's have been set - username
```
make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSUser_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSUser_
-timeout 120m
=== RUN TestAccAWSUser_importBasic
--- PASS: TestAccAWSUser_importBasic (14.24s)
=== RUN TestAccAWSUser_basic
--- PASS: TestAccAWSUser_basic (24.99s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 39.261s
```
Changes required:
* ECR Read func doesn't need to take ``registry_id` as it uses the
current account Id
* `name` wasn't being set in the ECR Read so the import was failing as
name wasn't found
```
make testacc TEST=./builtin/providers/aws
TESTARGS='-run=TestAccAWSEcrRepository_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/aws -v
-run=TestAccAWSEcrRepository_ -timeout 120m
=== RUN TestAccAWSEcrRepository_importBasic
--- PASS: TestAccAWSEcrRepository_importBasic (17.37s)
=== RUN TestAccAWSEcrRepository_basic
--- PASS: TestAccAWSEcrRepository_basic (16.05s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 33.437s
```
`virtual_machine`
Fixes#7275 - a state migration was missed when `enable_disk_uuid` was
merged
```
make testacc TEST=./builtin/providers/vsphere
TESTARGS='-run=TestVSphereVirtualMachineMigrateState'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/vsphere -v
-run=TestVSphereVirtualMachineMigrateState -timeout 120m
=== RUN TestVSphereVirtualMachineMigrateState
--- PASS: TestVSphereVirtualMachineMigrateState (0.00s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/vsphere
0.018s
```
this datasource allows terraform to work with externally modified state, e.g.
when you're using an ECS service which is continously updated by your CI via the
AWS CLI.
right now you'd have to wrap terraform into a shell script which looks up the
current image digest, so running terraform won't change the updated service.
using the aws_ecs_container_definition data source you can now leverage
terraform, removing the wrapper entirely.
There are currently no checks on username and endpoint in the provider
schema from being an empty value. This PR adds support to make sure that
endpoint and username are not empty strings as that can cause a panic
Results of the PR:
```
% terraform apply
There are warnings and/or errors related to your configuration. Please
fix these before continuing.
Errors:
* provider.mysql: Endpoint must not be an empty string
```
If an AWS Cookie Stickiness Policy is removed from the listener in
the AWS console the policy isn't deleted. Cross reference the policy
name with those assigned to the listener to determine if the policy
is actually being used.
Since this resource produces a list it feels more intuitive to give its
attribute a plural name, and since the noun "instance" already means
something specific in the AWS provider that doesn't apply here we use
"names" to indicate that these are availability zone names.
Also includes updating the docs to not show a dynamic count example for
now, since we don't support that yet.
When reading an AppCookieStickinessPolicy check for LoadBalancerNotFound
as well as PolicyNotFound. This prevents errors when when destroying a
policy on an ELB that no longer exists.
There were lots of hacky checks in the ARM VM resource to check for a
length of 1 param block
MaxItems was introduced so this PR updates to use MaxItems
- Tests for issue hashicorp/terraform#2143.
- Fixed package names since Triton deprecated the g3-series.
- Must supply SDC_URL when invoking tests.
Test will fail on metadata_3 but not on _2 as discussed with
@jen20 on 11 June 2016.
The work integrated in hashicorp/terraform#6322 silently broke the
ability to use remote state correctly. This commit adds a fix for that,
making use of the work integrated in hashicorp/terraform#7124.
In order to deal with outputs which are complex structures, we use a
forked version of the flatmap package - the difference in the version
this commit vs the github.com/hashicorp/terraform/flatmap package is
that we add in an additional key for map counts which state requires.
Because we bypass the normal helper/schema mechanism, this is not set
for us.
Because of the HIL type checking of maps, values must be of a homogenous
type. This is unfortunate, as it means we can no longer refer to outputs
as:
${terraform_remote_state.foo.output.outputname}
Instead we had to bring them to the top level namespace:
${terraform_remote_state.foo.outputname}
This actually does lead to better overall usability - and the BC
breakage is made better by the fact that indexing would have broken the
original syntax anyway.
We also add a real-world test and assert against specific values. Tests
which were previously acceptance tests are now run as unit tests, so
regression should be identified at a much earlier stage.
When using winrm config block, we had an address issue. This is no
longer a set but a list (As a list fits it more approp)
```
make testacc TEST=./builtin/providers/azurerm
TESTARGS='-run=TestAccAzureRMVirtualMachine_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/azurerm -v
-run=TestAccAzureRMVirtualMachine_ -timeout 120m
=== RUN TestAccAzureRMVirtualMachine_basicLinuxMachine
--- PASS: TestAccAzureRMVirtualMachine_basicLinuxMachine (587.80s)
=== RUN TestAccAzureRMVirtualMachine_tags
--- PASS: TestAccAzureRMVirtualMachine_tags (554.53s)
=== RUN TestAccAzureRMVirtualMachine_updateMachineSize
--- PASS: TestAccAzureRMVirtualMachine_updateMachineSize (612.52s)
=== RUN TestAccAzureRMVirtualMachine_basicWindowsMachine
--- PASS: TestAccAzureRMVirtualMachine_basicWindowsMachine (765.90s)
=== RUN TestAccAzureRMVirtualMachine_windowsUnattendedConfig
--- PASS: TestAccAzureRMVirtualMachine_windowsUnattendedConfig
(770.53s)
=== RUN TestAccAzureRMVirtualMachine_winRMConfig
--- PASS: TestAccAzureRMVirtualMachine_winRMConfig (827.90s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/azurerm
4119.192s
```
This commit cleans up the acceptance test formatting for the lbaas v2
resources. It also modifies the devstack script to enable the lbaas
v2 service for testing. Finally, this commit increases the timeout
for load balancer creation since it takes some time to do within
devstack.
false
Fixes#7035
A known issue in Terraform means that d.GetOk() on a bool which is false
will mean it doesn't get evaulated. Therefore, when people set
publicly_accessible to false, it will never get evaluated on the Create
We are going to make it default to false now
* provider/azurerm: DNS CNAME resource wasn't posting records
Azure changed the API for CNAME at some point and since then we haven't
been creating CNAME records. The API changes from []records to a single
record
This PR changes the schema for dns cnames to have a record parameter and
adds a deprecation warning around records. Talked with @jen20 on this
and we decided that it's currently broken and we should handle this as
part of 0.7 where there are other breaking changes
```
TF_LOG=1 make testacc TEST=./builtin/providers/azurerm
TESTARGS='-run=TestAccAzureRMDnsCNameRecord' 2>~/tf.log
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/azurerm -v
-run=TestAccAzureRMDnsCNameRecord -timeout 120m
=== RUN TestAccAzureRMDnsCNameRecord_basic
--- PASS: TestAccAzureRMDnsCNameRecord_basic (97.22s)
=== RUN TestAccAzureRMDnsCNameRecord_subdomain
--- PASS: TestAccAzureRMDnsCNameRecord_subdomain (94.94s)
=== RUN TestAccAzureRMDnsCNameRecord_updateRecords
--- PASS: TestAccAzureRMDnsCNameRecord_updateRecords (116.62s)
```
* Change DNS Records to removed rather than deprecated
Fixes#7053 where, when using `additional_unattend_config` in
`os_profile_windows_config` we got an error as follows:
```
azurerm_virtual_machine.test: [DEBUG] Error setting Virtual Machine
Storage OS Profile Windows Configuration: &errors.errorString{s:"Invalid
address to set: []string{\"os_profile_windows_config\", \"1534614206\",
\"additional_unattend_config\"}"}
```
Creating most google cloud resources uses the compute_operation to
wait for the creation to complete. However, the computeOperationWait*
functions always uses the global `config.Project`, instead of the resource-
specific one.
This means that creating resource in a project other than the main one
fails with a 404 on the operation resource.
This patch uses the project from google_compute_instance instead of the
global one.
The region returned by the API is always lowercase therefore when you specify a region uppercase in your config file it forces the droplet to be regenerated on every ```terraform apply``` (even when it is not needed).
Since the custom_configuration_parameters can't take dots, we cannot
set 'disk.EnableUUID'. This adds a parameter for this options that gets
added to a configSpec. This option causes the vm to mount disks by uuid
on the guest OS.
Fixed the problem where the root_block_device could cause an apply error
by reading back an "encrypted" parameter that was meant for an
ebs_block_device. "encrypted" is not part of the root_block_device
schema, since it can't be set explicitly.
Added a check in Create to fail when the root device is incorrectly
specified as an ebs_block_device, as this causes continual refreshing
due to mismatched state between root_block_device and ebs_block_device.
"encrypted" and "snapshot_id" should be guarded with ConflictsWith, but
that doesn't appear to work on nested resources despite #1926.
Fixes#7062
make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSElasticacheSubnetGroup'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSElasticacheSubnetGroup -timeout 120m
=== RUN TestAccAWSElasticacheSubnetGroup_basic
--- PASS: TestAccAWSElasticacheSubnetGroup_basic (44.62s)
=== RUN TestAccAWSElasticacheSubnetGroup_update
--- PASS: TestAccAWSElasticacheSubnetGroup_update (73.74s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 118.379s
* pr-6865:
provider/aws: Add db_param group to RDS Cluster Instance test
remove status attribute
support aurora instance's parameter group and modifyinstance
This commit ensures that all monitors have been disassociated from
the load balancing pool before the pool is deleted.
A test has been added to ensure that a full load balancing stack is
capable of handling an update to an instance, causing some components
to be rebuilt.
* Adding debug functionality to log debug api calls
* adding debug and refactoring tests
* more tweaks with tests
* updating documentation
* more refactoring of tests
* working through factor for testing
* removing logging that displays username and password
* more work on getting tests stable
When VPC is detached from VPN gateway, its VpcAttachment stays in place
just with state changed to "detached". Since terraform was not checking
attachment state, it used to think VPC gateway was still attached.
Add the iam_arn attribute to aws_cloudfront_origin_access_identity,
which computes the IAM ARN for a certain CloudFront origin access
identity.
This is necessary because S3 modifies the bucket policy if CanonicalUser
is sent, causing spurious diffs with aws_s3_bucket resources.
This brings over the work done by @apparentlymart and @radeksimko in
PR #3124, and converts it into a data source for the AWS provider:
This commit adds a helper to construct IAM policy documents using
familiar Terraform concepts. It makes Terraform-style interpolations
easier and resolves the syntax conflict between Terraform interpolations
and IAM policy variables by changing the latter to use &{...} for its
interpolations.
Its use is completely optional and users are free to go on using literal
heredocs, file interpolations or whatever else; this just adds another
option that fits more naturally into a Terraform config.
This an effort to address hashicorp/terraform#516.
Adding the Sensitive attribute to the resource schema, opening up the
ability for resource maintainers to mark some fields as sensitive.
Sensitive fields are hidden in the output, and, possibly in the future,
could be encrypted.
Closing off my other AWS availability zone branch, I'm adding tests for
the existing aws_availability_zones data source.
This closeshashicorp/terraform#4848.
This data source allows one to look up the most recent AMI for a specific
set of parameters, much like aws ec2 describe-images in the AWS CLI.
Basically a refresh of hashicorp/terraform#4396, in data source form.
This commit adds the newly required OS_EXT_GW environment variable to
the devstack acceptance environment build suite. It also fixes some
space formatting in a test.
* Add per user, role and group policy attachment
* Add docs for new IAM policy attachment resources.
* Make policy attachment resources manage only 1 entity<->policy attachment
* provider/aws: Tidy up IAM Group/User/Role attachments
When two rules differ only in source security group, EC2 APIs return
them as a single rule, but Terraform requires separate
aws_security_group_rule resources.
6bdab07174 changed Read to set source_security_group_id (and
cidr_blocks) from the rule returned from EC2 and chose the first
source_security_group_id arbitrarily, which is wrong.
Makes TestAccAWSSecurityGroupRule_PartialMatching_Source pass again.
Also adds a comment noting that there is a bug in the new resource
importing feature.
Fixes#6728.
This commit adds a data source with a single list, `instance` for the
schema which gets populated with the availability zones to which an
account has access.
Allow a cloud admin to target a specific tenant in which to allocate
a floating IP. This is useful when the cloud admin does not want to
delegate network privileges to the tenants or various Q&A scenarios.
resource
We had a line on the Update func that said:
```
Hash key can only be specified at creation, you cannot modify it.
```
The resource has now been changed to ForceNew on the hashkey
```
aws_dynamodb_table.demo-user-table: Refreshing state... (ID: Users)
aws_dynamodb_table.demo-user-table: Destroying...
aws_dynamodb_table.demo-user-table: Destruction complete
aws_dynamodb_table.demo-user-table: Creating...
aws_dynamodb_table.demo-user-table: Creation complete
```
The changes to allow for testing ID-only refresh conflict with passing
in "" as Config for tests. In this case we instead construct a config
with a known-non-existent bucket name.
Changed schema type for disks to support dynamic non-ordered disk
swapping. All Disk attributes have been made non ForceNew since
any changes should be handled in the upgrade() function.
Added 'name' attribute to disks to act as a unique
identifier for when users request for new disks. It is also used as
the filename for the new disk. Templates are considered immutable.
The openstack_networking_subnet_v2 resource was originally designed
to have DHCP disabled by default; however, a bug in the original
implementation caused DHCP to always be enabled and never be
disabled. This bug was fixed in #6052.
Recent discussions have shown that users prefer if DHCP is enabled
by default. This commit implements makes the change.
When stage_name is not passed to the resource
aws_api_gateway_deployment a terraform apply will fail. This is
because the stage_name is required and not optional.
* Grafana provider
* grafana_data_source resource.
Allows data sources to be created in Grafana. Supports all data source
types that are accepted in the current version of Grafana, and will
support any future ones that fit into the existing structure.
* Vendoring of apparentlymart/go-grafana-api
This is in anticipation of adding a Grafana provider plugin.
* grafana_dashboard resource
* Website documentation for the Grafana provider.
apply
The IP COnfiguration block of `azurerm_network_interface` didn't have a
hash created in a way that changes to the optional params were being
picked up:
```
~ azurerm_network_interface.test
ip_configuration.273485505.name: "testconfiguration1" => ""
ip_configuration.273485505.private_ip_address_allocation: "dynamic" => ""
ip_configuration.273485505.subnet_id: "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/acctestrg/providers/Microsoft.Network/virtualNetworks/acctvn/subnets/acctsub" => ""
ip_configuration.~273485505.load_balancer_backend_address_pools_ids.#: "" => "<computed>"
ip_configuration.~273485505.load_balancer_inbound_nat_rules_ids.#: "" => "<computed>"
ip_configuration.~273485505.name: "" => "testconfiguration1"
ip_configuration.~273485505.private_ip_address: "" => "<computed>"
ip_configuration.~273485505.private_ip_address_allocation: "" => "dynamic"
ip_configuration.~273485505.public_ip_address_id: "" => "${azurerm_public_ip.test.id}"
ip_configuration.~273485505.subnet_id: "" => "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/acctestrg/providers/Microsoft.Network/virtualNetworks/acctvn/subnets/acctsub"
```
This caused the following error:
```
Error applying plan:
1 error(s) occurred:
* azurerm_network_interface.test: diffs didn't match during apply. This is a bug with Terraform and should be reported as a GitHub Issue.
Please include the following information in your report:
```
Notice that the hash didn't change. This change adds the remaining optional params to the hash so that the hash id will change.
```
~ azurerm_network_interface.test
ip_configuration.4255411321.load_balancer_backend_address_pools_ids.#: "" => "<computed>"
ip_configuration.4255411321.load_balancer_inbound_nat_rules_ids.#: "" => "<computed>"
ip_configuration.4255411321.name: "" => "testconfiguration1"
ip_configuration.4255411321.private_ip_address: "" => "<computed>"
ip_configuration.4255411321.private_ip_address_allocation: "" => "dynamic"
ip_configuration.4255411321.public_ip_address_id: "" => "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/acctestrg/providers/Microsoft.Network/publicIPAddresses/public-ip"
ip_configuration.4255411321.subnet_id: "" => "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/acctestrg/providers/Microsoft.Network/virtualNetworks/acctvn/subnets/acctsub"
ip_configuration.966273186.name: "testconfiguration1" => ""
ip_configuration.966273186.private_ip_address_allocation: "dynamic" => ""
ip_configuration.966273186.subnet_id: "/subscriptions/34ca515c-4629-458e-bf7c-738d77e0d0ea/resourceGroups/acctestrg/providers/Microsoft.Network/virtualNetworks/acctvn/subnets/acctsub" => ""
```
This allows the Update to work as expected :)
```
azurerm_network_interface.test: Modifications complete
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
```
* provider/datadog Update go-datadog-api.
* provider/datadog Add support for "require_full_window" and "locked".
* provider/datadog Update tests, update doco, gofmt.
* provider/datadog Add options to update resource.
* provider/datadog "require_full_window" defaults to True, "locked" to False. Use
those initial values as the starting configuration.
* provider/datadog Update notify_audit tests to use the default value for
testAccCheckDatadogMonitorConfig and a custom value for
testAccCheckDatadogMonitorConfigUpdated.
This catches a situation where the code ignores setting the option on creation,
and the update function merely asserts the default value, versus actually changing
the value.
This commit forward ports the changes made for 0.6.17, in order to store
the type and sensitive flag against outputs.
It also refactors the logic of the import for V0 to V1 state, and
fixes up the call sites of the new format for outputs in V2 state.
Finally we fix up tests which did not previously set a state version
where one is required.
`azurerm_storage_account` access keys
Please note that we do NOT have the ability to manage the access keys -
we are just getting the keys that the account creates for us. To manage
the keys, you would need to use the azure portal still
random_shuffle takes a list of strings and returns a new list with the
same items in a random permutation.
Optionally allows the result list to be a different length than the
input list. A shorter result than input results in some items being
excluded. A longer result than input results in some items being
repeated, but never more often than the number of input items.
This resource generates a cryptographically-strong set of bytes and
provides them as base64, hexadecimal and decimal string representations.
It is intended to be used for generating unique ids for resources
elsewhere in the configuration, and thus the "keepers" would be set to
any ForceNew attributes of the target resources, so that a new id is
generated each time a new resource is generated.
This provider will have logical resources that allow Terraform to "manage"
randomness as a resource, producing random numbers on create and then
retaining the outcome in the state so that it will remain consistent
until something explicitly triggers generating new values.
Managing randomness in this way allows configurations to do things like
random distributions and ids without causing "perma-diffs".
A companion to the null_resource resource, this is here primarily to
enable manual quick testing of data sources workflows without depending
on any external services.
The "inputs" map gets copied to the computed "outputs" map on read,
"rand" gives a random number to exercise cases with constantly-changing
values (an anti-pattern!), and "has_computed_default" is settable in
config but computed if not set.
For backward compatibility we will continue to support using the data
sources that were formerly logical resources as resources for the moment,
but we want to warn the user about it since this support is likely to
be removed in future.
This is done by adding a new "deprecation message" feature to
schema.Resource, but for the moment this is done as an internal feature
(not usable directly by plugins) so that we can collect additional
use-cases and design a more general interface before creating a
compatibility constraint.
As a first example of a real-world data source, the pre-existing
terraform_remote_state resource is adapted to be a data source. The
original resource is shimmed to wrap the data source for backward
compatibility.
As requested in #4822, add support for a KMS Key ID (ARN) for Db
Instance
```
make testacc TEST=./builtin/providers/aws
TESTARGS='-run=TestAccAWSDBInstance_kmsKey' 2>~/tf.log
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /vendor/)
TF_ACC=1 go test ./builtin/providers/aws -v
-run=TestAccAWSDBInstance_kmsKey -timeout 120m
=== RUN TestAccAWSDBInstance_basic
--- PASS: TestAccAWSDBInstance_basic (587.37s)
=== RUN TestAccAWSDBInstance_kmsKey
--- PASS: TestAccAWSDBInstance_kmsKey (625.31s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 1212.684s
```
missing
Fixes#6625
When an SNS topic subscription was created with TF and then removed via
the AWS Console, Terraform threw an error:
```
* aws_sns_topic_subscription.testme: NotFound: Subscription does not
* exist
status code: 404, request id: a22e7ed7-3630-5a8a-b767-317ac1440e24
```
This PR will remove the topic subscription from state on a NotFound and
will then readd the subscripton
Auto-generating an Instance Template name (or just its suffix) allows the
create_before_destroy lifecycle option to function correctly on the
Instance Template resource. This in turn allows Instance Group Managers
to be updated without being destroyed.
`on_premises_instance_tag_filter`
When setting `on_premises_instance_tag_filter`, Terraform was not
pushing the changes on the cReate (due to a spelling mistake). A second
apply would push the tags and then cause a panic. Terraform was building
a ec2.Tagfilter struct without checking for optional values. When the
TagFilter was being dereferenced, it caused a panic
This commit adds the groundwork for supporting module outputs of types
other than string. In order to do so, the state version is increased
from 1 to 2 (though the "public-facing" state version is actually as the
first state file was binary).
Tests are added to ensure that V2 (1) state is upgraded to V3 (2) state,
though no separate read path is required since the V2 JSON will
unmarshal correctly into the V3 structure.
Outputs in a ModuleState are now of type map[string]interface{}, and a
test covers round-tripping string, []string and map[string]string, which
should cover all of the types in question.
Type switches have been added where necessary to deal with the
interface{} value, but they currently default to panicking when the input
is not a string.
The `name` attribute will always be normalized to a FQDN, with a trailing "dot"
at the end when returned from the API.
We store the name as it's provided in the configuration, so "www" stays as "www"
and "www.terraformtesting.io." stays as "www.terraformtesting.io.".
The problem here is that if we use a full name as above, and the configuraiton
does *not* include the trailing dot, the API will return a version that does,
and we'll have a conflict.
This is particularly bad when we have a lifecycle block with
`create_before_destroy`; the record will get an update posted (which ends up
being a no-op on AWS's side), but then we'll delete the same record immediately
after, resulting in no record at all.
This PR addresses that by trimming the trailing dot from the `name` when saving
to state. We migrate existing state to match, to avoid false-positive diffs.
* provider/fastly: Add support for Conditions for Fastly Services
Docs here:
- https://docs.fastly.com/guides/conditions/
Also Bump go-fastly version for domain support in S3 Logging
* New top level AWS resource aws_eip_association
* Add documentation for aws_eip_association
* Add tests for aws_eip_association
* provider/aws: Change `aws_elastic_ip_association` to have computed
parameters
The AWS API was send ing more parameters than we had set. Therefore,
Terraform was showing constant changes when plans were being formed
* Adding private ip address reference
* adding private ip address reference
* Updating the docs.
* Removing optional attrib from private_ip_address
Removing optional attribute from private_ip_address, this element is only being used in the read.
* Selecting the first element instead of using a loop for now.
Change this to a loop when https://github.com/Azure/azure-sdk-for-go/issues/259 is fixed
The `storage_data_disk` was trying to use vhd_url rather than vhd_uri.
This was causing an error on creating a new data_disk as part of a VM
Also added validation as data_disks can only be 1 - 1023 GB in size
Added the hosted_zone_id attribute, which aliases to the Route 53
zone ID that can be used to route Alias Resource Record Sets to.
This fixeshashicorp/terraform#6489.
ssh_keys were throwing an error similar to this:
```
* azurerm_virtual_machine.test: [DEBUG] Error setting Virtual Machine
* Storage OS Profile Linux Configuration: &errors.errorString{s:"Invalid
* address to set: []string{\"os_profile_linux_config\", \"0\",
* \"ssh_keys\"}"}
```
This was because of nesting of Set within a Set in the schema. By
changing this to a List within a Set, the schema works as expected. This
means we can now set SSH Keys on VMs. This has been tested using a
remote-exec and a connection block with the ssh key
```
azurerm_virtual_machine.test: Still creating... (2m10s elapsed)
azurerm_virtual_machine.test (remote-exec): Connected!
azurerm_virtual_machine.test (remote-exec): CONNECTED!
```
Change the AWS DB Instance to now include the DB Option Group param. Adds a test to prove that it works
Add acceptance tests for the AWS DB Option Group work. This ensures that Options can be added and updated
Documentation for the AWS DB Option resource
automated_snapshot_retention_period
The default value for `automated_snapshot_retention_period` is 1.
Therefore, it can be included in the `CreateClusterInput` without
needing to check that it is set.
This was actually stopping people from setting the value to 0 (disabling
the snapshots) as there is an issue in `d.GetOk()` evaluating 0 for int
adminPassword
The Azure API never returns the AdminPAssword (as is correct) from the
Read API call. Therefore on Create, we do not set the AdminPassword of
the vm as part of the state. The Same func is used for Create & Update,
therefore when we changed anything on the VM, we were getting the
following error:
```
statusCode:Conflict
serviceRequestId:f498a6c8-6e7a-420f-9788-400f18078921
statusMessage:{"error":{"code":"PropertyChangeNotAllowed","target":"adminPassword","message":"Changing property 'adminPassword' is not allowed."}}
```
To fix this, we need to excldue the AdminPassword from the Update func
if it is empty
On Create, notify_no_data was being ignored.
On Read and Update, no_data_timeframe was being misused.
There was also a redundant read of escalation_message on Create.
For a long time now, the diff logic has relied on the behavior of
`mapstructure.WeakDecode` to determine how various primitives are
converted into strings. The `schema.DiffString` function is used for
all primitive field types: TypeBool, TypeInt, TypeFloat, and TypeString.
The `mapstructure` library's string representation of booleans is "0"
and "1", which differs from `strconv.FormatBool`'s "false" and "true"
(which is used in writing out boolean fields to the state).
Because of this difference, diffs have long had the potential for
cosmetically odd but semantically neutral output like:
"true" => "1"
"false" => "0"
So long as `mapstructure.Decode` or `strconv.ParseBool` are used to
interpret these strings, there's no functional problem.
We had our first clear functional problem with #6005 and friends, where
users noticed diffs like the above showing up unexpectedly and causing
troubles when `ignore_changes` was in play.
This particular bug occurs down in Terraform core's EvalIgnoreChanges.
There, the diff is modified to account for ignored attributes, and
special logic attempts to handle properly the situation where the
ignored attribute was going to trigger a resource replacement. That
logic relies on the string representations of the Old and New fields in
the diff to be the same so that it filters properly.
So therefore, we now get a bug when a diff includes `Old: "0", New:
"false"` since the strings do not match, and `ignore_changes` is not
properly handled.
Here, we introduce `TypeBool`-specific normalizing into `finalizeDiff`.
I spiked out a full `diffBool` function, but figuring out which pieces
of `diffString` to duplicate there got hairy. This seemed like a simpler
and more direct solution.
Fixes#6005 (and potentially others!)
- Addresses the issue when local state file has logging_config populated and the user
disables the configuration via the UI (or in this case an
application of the TF config). This will now properly set the
logging_config during the read operation and identify the state as
diverging
Fixes#6390
* TF-6256 - SG Rule Retry
- Preferring slower but consistent runs when AWS API calls do not properly return the SG Rule in the list of ingress/egress rules.
- Testing has shown that several times that we had to exceed 20 attempts
before the SG was actually returned
* TF-6256 - Refactor of rule lookup
- Adjusting to use resource.Retry
- Extract lookup method for matching ipPermissions set
Here is an example that will setup the following:
+ An SSH key resource.
+ A virtual server resource that uses an existing SSH key.
+ A virtual server resource using an existing SSH key and a Terraform managed SSH key (created as "test_key_1" in the example below).
(create this as sl.tf and run terraform commands from this directory):
```hcl
provider "softlayer" {
username = ""
api_key = ""
}
resource "softlayer_ssh_key" "test_key_1" {
name = "test_key_1"
public_key = "${file(\"~/.ssh/id_rsa_test_key_1.pub\")}"
# Windows Example:
# public_key = "${file(\"C:\ssh\keys\path\id_rsa_test_key_1.pub\")}"
}
resource "softlayer_virtual_guest" "my_server_1" {
name = "my_server_1"
domain = "example.com"
ssh_keys = ["123456"]
image = "DEBIAN_7_64"
region = "ams01"
public_network_speed = 10
cpu = 1
ram = 1024
}
resource "softlayer_virtual_guest" "my_server_2" {
name = "my_server_2"
domain = "example.com"
ssh_keys = ["123456", "${softlayer_ssh_key.test_key_1.id}"]
image = "CENTOS_6_64"
region = "ams01"
public_network_speed = 10
cpu = 1
ram = 1024
}
```
You'll need to provide your SoftLayer username and API key,
so that Terraform can connect. If you don't want to put
credentials in your configuration file, you can leave them
out:
```
provider "softlayer" {}
```
...and instead set these environment variables:
- **SOFTLAYER_USERNAME**: Your SoftLayer username
- **SOFTLAYER_API_KEY**: Your API key
IPv6 support added.
We support 1 IPv6 address per interface. It seems like the vSphere SDK supports more than one, since it's provided as a list.
I can change it to support more than one address. I decided to stick with one for now since that's how the configuration parameters
had been set up by other developers.
The global gateway configuration option has been removed. Instead the user should specify a gateway on NIC level (ipv4_gateway and ipv6_gateway).
For now, the global gateway will be used as a fallback for every NICs ipv4_gateway.
The global gateway configuration option has been marked as deprecated.
* added update function with support for vcpu and memory
* waiting for vmware tools redundant with WaitForIP
* proper error handling of PowerOn task
* added test cases for update memory and vcpu
* reboot flag
this implements two new resource types:
* openstack_networking_secgroup_v2 - create a neutron security group
* openstack_networking_secgroup_rule_v2 - create a newutron security
group rule
Unlike their nova counterparts the neutron security groups allow a user
to specify the target tenant_id allowing a cloud admin to create per
tenant resources.
* Adding File Resource for vSphere provider
Allows for file upload to vSphere at specified location. This also
includes update for moving or renaming of file resources.
* Ensuring required parameters are provided
stack72