Fixes: #14535
When in a `restricted` cloud, we should fall back to the old method of
tagging. Before this change we saw the following:
```
% terraform apply ✭
aws_instance.foo: Creating...
ami: "" => "ami-0fa3c42c"
associate_public_ip_address: "" => "<computed>"
availability_zone: "" => "<computed>"
ebs_block_device.#: "" => "<computed>"
ephemeral_block_device.#: "" => "<computed>"
instance_state: "" => "<computed>"
instance_type: "" => "m1.small"
ipv6_address_count: "" => "<computed>"
ipv6_addresses.#: "" => "<computed>"
key_name: "" => "<computed>"
network_interface.#: "" => "<computed>"
network_interface_id: "" => "<computed>"
placement_group: "" => "<computed>"
primary_network_interface_id: "" => "<computed>"
private_dns: "" => "<computed>"
private_ip: "" => "<computed>"
public_dns: "" => "<computed>"
public_ip: "" => "<computed>"
root_block_device.#: "" => "<computed>"
security_groups.#: "" => "<computed>"
source_dest_check: "" => "true"
subnet_id: "" => "<computed>"
tags.%: "" => "1"
tags.foo: "" => "bar"
tenancy: "" => "<computed>"
volume_tags.%: "" => "<computed>"
vpc_security_group_ids.#: "" => "<computed>"
aws_instance.foo: Creation complete (ID: i-0009f227ae24791b9)
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
% terraform plan ✭
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.
aws_instance.foo: Refreshing state... (ID: i-0009f227ae24791b9)
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.
~ aws_instance.foo
tags.%: "0" => "1"
tags.foo: "" => "bar"
Plan: 0 to add, 1 to change, 0 to destroy.
```
After this patch, we see the following:
```
% terraform apply ✹ ✭
[WARN] /Users/stacko/Code/go/bin/terraform-provider-aws overrides an internal plugin for aws-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
aws_instance.foo: Creating...
ami: "" => "ami-0fa3c42c"
associate_public_ip_address: "" => "<computed>"
availability_zone: "" => "<computed>"
ebs_block_device.#: "" => "<computed>"
ephemeral_block_device.#: "" => "<computed>"
instance_state: "" => "<computed>"
instance_type: "" => "m1.small"
ipv6_address_count: "" => "<computed>"
ipv6_addresses.#: "" => "<computed>"
key_name: "" => "<computed>"
network_interface.#: "" => "<computed>"
network_interface_id: "" => "<computed>"
placement_group: "" => "<computed>"
primary_network_interface_id: "" => "<computed>"
private_dns: "" => "<computed>"
private_ip: "" => "<computed>"
public_dns: "" => "<computed>"
public_ip: "" => "<computed>"
root_block_device.#: "" => "<computed>"
security_groups.#: "" => "<computed>"
source_dest_check: "" => "true"
subnet_id: "" => "<computed>"
tags.%: "" => "1"
tags.foo: "" => "bar"
tenancy: "" => "<computed>"
volume_tags.%: "" => "<computed>"
vpc_security_group_ids.#: "" => "<computed>"
aws_instance.foo: Creation complete (ID: i-04cd122e28f167a14)
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
% terraform plan ✹ ✭
[WARN] /Users/stacko/Code/go/bin/terraform-provider-aws overrides an internal plugin for aws-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.
aws_instance.foo: Refreshing state... (ID: i-04cd122e28f167a14)
No changes. Infrastructure is up-to-date.
This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, Terraform
doesn't need to do anything.
```
Fixes: #14032
When you are using an IPv6 address directly to an instance, it was
causing the ipv6_address_count to try and ForceNew resource. It wasn't
marked as computed
I was able to see this here:
```
-/+ aws_instance.test
ami: "ami-c5eabbf5" => "ami-c5eabbf5"
associate_public_ip_address: "false" => "<computed>"
availability_zone: "us-west-2a" => "<computed>"
ebs_block_device.#: "0" => "<computed>"
ephemeral_block_device.#: "0" => "<computed>"
instance_state: "running" => "<computed>"
instance_type: "t2.micro" => "t2.micro"
ipv6_address_count: "1" => "0" (forces new resource)
ipv6_addresses.#: "1" => "1"
ipv6_addresses.0: "2600:1f14:bb2:e501::10" => "2600:1f14:bb2:e501::10"
key_name: "" => "<computed>"
network_interface.#: "0" => "<computed>"
network_interface_id: "eni-d19115ec" => "<computed>"
placement_group: "" => "<computed>"
primary_network_interface_id: "eni-d19115ec" => "<computed>"
private_dns: "ip-10-20-1-252.us-west-2.compute.internal" => "<computed>"
private_ip: "10.20.1.252" => "<computed>"
public_dns: "" => "<computed>"
public_ip: "" => "<computed>"
root_block_device.#: "1" => "<computed>"
security_groups.#: "0" => "<computed>"
source_dest_check: "true" => "true"
subnet_id: "subnet-3fdfb476" => "subnet-3fdfb476"
tags.%: "1" => "1"
tags.Name: "stack72" => "stack72"
tenancy: "default" => "<computed>"
volume_tags.%: "0" => "<computed>"
vpc_security_group_ids.#: "1" => "<computed>"
```
It now works as expected:
```
% terraform plan ✹ ✭
[WARN] /Users/stacko/Code/go/bin/terraform-provider-aws overrides an internal plugin for aws-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.
aws_vpc.foo: Refreshing state... (ID: vpc-fa61669d)
aws_subnet.foo: Refreshing state... (ID: subnet-3fdfb476)
aws_internet_gateway.foo: Refreshing state... (ID: igw-70629a17)
aws_route_table.test: Refreshing state... (ID: rtb-0a52e16c)
aws_instance.test: Refreshing state... (ID: i-0971755345296aca5)
aws_route_table_association.a: Refreshing state... (ID: rtbassoc-b12493c8)
No changes. Infrastructure is up-to-date.
This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, Terraform
doesn't need to do anything.
```
With an EC2 instance that only had a single network interface, the primary interface, the Update function would call `ModifyInstanceAttribute()` on the target instance. This would only work if there was a single network interface attached to the EC2 instance. If, however, a secondary network interface was attached to the instance, the `ModifyInstanceAttribute()` API call would fail with the following error message:
> There are multiple interfaces attached to instance 'i-XXXXX'. Please specify an interface ID for the operation instead.
After this changeset, modifying instance security groups now makes the correct call to `ModifyNetworkInterfaceAttribute()` in order to modify the list of security groups on the primary network interface, as initially configured during the instances creation.
This change is also safe from an instance that has a non-default primary network interface, as the instance attribute `vpc_security_group_ids` conflicts with the new `network_interface` attribute.
Test Output:
```
$ make testacc TEST=./builtin/providers/aws TESTARGS="-run=TestAccAWSInstance_addSecurityGroupNetworkInterface"
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/05/08 17:52:42 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSInstance_addSecurityGroupNetworkInterface -timeout 120m
=== RUN TestAccAWSInstance_addSecurityGroupNetworkInterface
--- PASS: TestAccAWSInstance_addSecurityGroupNetworkInterface (327.75s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 327.756s
```
The default value for `source_dest_check` needs to remain the same, so as not to break any backwards compatibility, however, adding a new `network_interface` parameter with a pre-configured network_interface that has `source_dest_check` set to false throws a diff after initial apply. Since we don't want to change `source_dest_check` to computed in order to not break sane defaults, ignore the diff thrown if `network_interface` attributes are configured on an instance.
```
$ make testacc TEST=./builtin/providers/aws TESTARGS="-run=TestAccAWSInstance_primaryNetworkInterfaceSourceDestCheck"
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/04/28 16:26:02 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSInstance_primaryNetworkInterfaceSourceDestCheck -timeout 120m
=== RUN TestAccAWSInstance_primaryNetworkInterfaceSourceDestCheck
--- PASS: TestAccAWSInstance_primaryNetworkInterfaceSourceDestCheck (134.20s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 134.211s
```
```
$ make testacc TEST=./builtin/providers/aws TESTARGS="-run=TestAccAWSInstance_sourceDestCheck"
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/04/28 16:15:14 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSInstance_sourceDestCheck -timeout 120m
=== RUN TestAccAWSInstance_sourceDestCheck
--- PASS: TestAccAWSInstance_sourceDestCheck (179.81s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 179.815s
```
Fixes: #14068
Fixes: #14049
The China and Gov regions do not support the new way of tagging
instances and volumes on creation. Therefore, we need to hack this to
make sure we don't try and set these on instance creation
Fixes: #14003
When an EBS volume was created and tags were specified on that resource
and NOT the aws_instance it was attached to, the tags would be removed
on subsequent Terraform runs.
We need to set volume_tags to be Computed to allow for changes to EBS
volumes not created as part of the instance but that are attached to the
instance
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSInstance_volumeTagsComputed'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/04/27 07:33:36 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSInstance_volumeTagsComputed -timeout 120m
=== RUN TestAccAWSInstance_volumeTagsComputed
--- PASS: TestAccAWSInstance_volumeTagsComputed (151.37s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 151.411s
```
Fixes: #13173
We now tag at instance creation and introduced `volume_tags` that can be
set so that all devices created on instance creation will receive those
tags
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSInstance_volumeTags' 2 ↵ ✚ ✭
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/04/26 06:30:48 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSInstance_volumeTags -timeout 120m
=== RUN TestAccAWSInstance_volumeTags
--- PASS: TestAccAWSInstance_volumeTags (214.31s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 214.332s
```
machines
Fixes: #12898
The way aws_instance works is that we call the Create func then the
Update func then the Read func. The way the work to implement the change
to iam_instance_profile was added meant that when a machine was created
with an iam_instance_profile, it would then try and update that
iam_instance_profile because the state hadn't been updated at that point
We have changed the Update func to only check for the change to
iam_instance_profile when it *is an existing machine* - this will solve
the problem of those bringing up new machines and getting hit with the
permissions error
As requested, added a test that adds an IAM Instance Profile from
creation
```
% make testacc TEST=./builtin/providers/aws TESTARGS='-run=TestAccAWSInstance_withIamInstanceProfile'
==> Checking that code complies with gofmt requirements...
go generate $(go list ./... | grep -v /terraform/vendor/)
2017/03/21 17:51:32 Generated command/internal_plugin_list.go
TF_ACC=1 go test ./builtin/providers/aws -v -run=TestAccAWSInstance_withIamInstanceProfile -timeout 120m
=== RUN TestAccAWSInstance_withIamInstanceProfile
--- PASS: TestAccAWSInstance_withIamInstanceProfile (154.29s)
PASS
ok github.com/hashicorp/terraform/builtin/providers/aws 154.325s
```
Previously the `root_block_device` config map was a `schema.TypeSet` with an empty `Set` function, and a hard-limit of 1 on the attribute block.
This prevented a user from making any real changes inside the attribute block, thus leaving the user with a `Apply complete!` message, and nothing changed.
The schema API has since been updated, and we can now specify the `root_block_device` as a `schema.TypeList` with `MaxItems` set to `1`. This fixes the issue, and allows the user to update the `aws_instance`'s `root_block_device` attribute, and see changes actually propagate.
Fixes#8455, #5390
This add a new `no_device` attribute to `ephemeral_block_device` block,
which allows users omit ephemeral devices from AMI's predefined block
device mappings, which is useful for EBS-only instance types.
Make sure to hash base64 decoded value since user_data might be given
either raw bytes or base64 value.
This helps https://github.com/hashicorp/terraform/issues/1887 somewhat
as now you can:
1) Update user_data in AWS console.
2) Respectively update user_data in terraform code.
3) Just refresh terraform state and it should not report any changes.
terraform run
Fixes#3550
The simple fix here was to check if the Resource was new (to set the
value the first time) then check it has changed each time
I was able to see from the TF log the following:
```
Config
resource "aws_vpc" "foo" {
cidr_block = "10.10.0.0/16"
}
resource "aws_subnet" "foo" {
cidr_block = "10.10.1.0/24"
vpc_id = "${aws_vpc.foo.id}"
}
resource "aws_instance" "foo" {
ami = "ami-4fccb37f"
instance_type = "m1.small"
subnet_id = "${aws_subnet.foo.id}"
source_dest_check = false
disable_api_termination = true
}
```
No longer caused any Modifying source_dest_check entries in the LOG
Expose the network interface ID that is created with a new instance.
This can be useful when associating an existing elastic IP to the
default interface on an instance that has multiple network interfaces.
* Don't Base64-encode EC2 userdata if it is already Base64 encoded
The user data may be Base64 encoded already - for example, if it has been
generated by a template_cloudinit_config resource.
* Add encoded user_data to aws_instance acceptance test
Paul Stack