When `force_destroy` was specifed on an `aws_iam_user` resource, only IAM
access keys and the login profile were destroyed. If a multi-factor auth
device had been activated for that user, deletion would fail as follows:
```
* aws_iam_user.testuser1: Error deleting IAM User testuser1: DeleteConflict: Cannot delete entity, must delete MFA device first.
status code: 409, request id: aa41b1b7-ac4d-11e6-bb3f-3b4c7a310c65
```
This commit iterates over any of the user's MFA devices and deactivates
them before deleting the user. It follows a pattern similar to that used
to remove users' IAM access keys before deletion.
```
$ make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSUser_'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2016/11/20 17:09:00 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSUser_ -timeout 120m
=== RUN TestAccAWSUser_importBasic
--- PASS: TestAccAWSUser_importBasic (5.70s)
=== RUN TestAccAWSUser_basic
--- PASS: TestAccAWSUser_basic (11.12s)
PASS
ok github.com/rhenning/terraform/builtin/providers/aws 20.840s
```
The docs for the CreateDBInstance API call include quite a bit more information about each individual option, (for example `Engine` has each of the possible options listed, whilst the cli reference doesn't).
This commit adds the openstack_compute_volume_attach_v2 resource. This
resource enables a volume to be attached to an instance by using the
OpenStack Compute (Nova) v2 volumeattach API.
This commit adds the openstack_blockstorage_volume_attach_v2 resource. This
resource enables a volume to be attached to an instance by using the OpenStack
Block Storage (Cinder) v2 API.
It makes for sense for this to happen in State.prune(). Also move a
redundant pruning from ResourceState.init, and make sure
ResourceState.prune is called from the parent's prune method.
existing example returns an error like the following should you try to
run `terraform plan` against it:
Error reading config for aws_subnet[example]: data.aws_availability_zone.name_suffix: data variables must be four parts: data.TYPE.NAME.ATTR in:
${cidrsubnet(aws_vpc.example.cidr_block, 4, var.az_number[data.aws_availability_zone.name_suffix])}
Needed due to work done in 95d37ea, we may need to adjust
hasComputedSubKeys to propagate NewComputed in the same way that we
have added "~", however will wait for comment from @mitchellh.
This covers:
* Complex sets with computed fields in a set
* Complex lists with computed fields in a set
Adding a test to test basic lists with computed fields seemed to fail,
but possibly for an unrelated reason (the list returned as nil). The fix
to this inparticular case may be out of the scope of this specific
issue.
Reference gist and details in hashicorp/terraform#9171.
This fixes some edge-ish cases where a set in a config has a set or list
in it that contains computed values, but non-set or list values in the
parent do not.
This can cause "diffs didn't match during apply" errors in a scenario
such as when a set's hash is calculated off of child items (including
any sub-lists or sets, as it should be), and the hash changes between
the plan and apply diffs due to the computed values present in the
sub-list or set items. These will be marked as computed, but due to the
fact that the function was not iterating over the list or set items
properly (ie: not adding the item number to the address, so
set.0.set.foo was being yielded instead of set.0.set.0.foo), these
computed values were not being properly propagated to the parent set to
be marked as computed.
Fixeshashicorp/terraform#6527.
Fixeshashicorp/terraform#8271.
This possibly fixes other non-CloudFront related issues too.
Fixes a case where ResourceConfig.get inadvertently returns a nil value.
Add an integration test where assigning a map to a list via
interpolation would panic.
We allow variables to have descriptions specified, as additional context
for a module user as to what should be provided for a given variable.
We previously lacked a similar mechanism for outputs. Since they too are
part of a module's public interface, it makes sense to be able to add
descriptions for these for symmetry's sake.
This change makes a "description" attribute valid within an "output"
configuration block and stores it within the configuration data structure,
but doesn't yet do anything further with it. For now this is useful only
for third-party tools that might parse a module's config to generate
user documentation; later we could expose the descriptions as part of
the "apply" output, but that is left for a separate change.
Also fixed tests failing auth caused by getStorageAccountAccessKey returning the
key name rather than the value
TF_ACC= go test ./state/remote -v -run=TestAz -timeout=10m -parallel=4
=== RUN TestAzureClient_impl
--- PASS: TestAzureClient_impl (0.00s)
=== RUN TestAzureClient
2016/11/18 13:57:34 [DEBUG] New state was assigned lineage "96037426-f95e-45c3-9183-6c39b49f590b"
2016/11/18 13:57:34 [TRACE] Preserving existing state lineage "96037426-f95e-45c3-9183-6c39b49f590b"
--- PASS: TestAzureClient (130.60s)
=== RUN TestAzureClientEmptyLease
2016/11/18 13:59:44 [DEBUG] New state was assigned lineage "d9997445-1ebf-4b2c-b4df-15ae152f6417"
2016/11/18 13:59:44 [TRACE] Preserving existing state lineage "d9997445-1ebf-4b2c-b4df-15ae152f6417"
--- PASS: TestAzureClientEmptyLease (128.15s)
=== RUN TestAzureClientLease
2016/11/18 14:01:55 [DEBUG] New state was assigned lineage "85912a12-2e0e-464c-9886-8add39ea3a87"
2016/11/18 14:01:55 [TRACE] Preserving existing state lineage "85912a12-2e0e-464c-9886-8add39ea3a87"
--- PASS: TestAzureClientLease (138.09s)
PASS
ok github.com/hashicorp/terraform/state/remote 397.111s
* provider/github: add GitHub labels resource
Provides a GitHub issue label resource.
This resource allows easy management of issue labels for an
organisation's repositories. A name, and a color can be set.
These attributes can be updated without creating a new resource.
* provider/github: add documentation for GitHub issue labels resource
* provider/aws: Add aws_alb_listener data source
This adds the aws_alb_listener data source to get information on an AWS
Application Load Balancer listener.
The schema is slightly modified (only option-wise, attributes are the
same) and we use the aws_alb_listener resource read function to get the
data.
Note that the HTTPS test here may fail due until
hashicorp/terraform#10180 is merged.
* provider/aws: Add aws_alb_listener data source docs
Now documented.
When using the static NAT resource, you no longer have to specify a `network_id`. This can be inferred from the choosen `virtual_machine_id` and/or the `vm_guest_ip`.
- Currently the disable_checkpoint setting from $HOME/.terraformrc is never
respsected due to:
-- The runCheckpoint go routine being fired off prior to loading configuration
-- The config.Merge method not actually merging in the c2s settings
Paul Stack