This commit follows suit of #1897 by fixing volume-related
parameters which allow the volume attach acceptance test
to work. It also re-enables the volume attach test.
This reworks the template lifecycle a bit such that we get nicer diff
behavior.
First, we tick ForceNew on for both filename and vars, so that the diff
indicates that the template will be "replaced" on change. This is mostly
cosmetic, but it also tracks conceptually with the fact that the
identifier we use is a hash of the contents, so any change essentially
makes a "new resource".
Second, we change the Exists implementation to only return `false` when
there has been a change in the rendered template. This lets descendent
resources see the computed value changing so that they'll properly
trigger in the plan.
Fixes#1898
Refs #1866 (but does not fix, there's another deeper issue there)
I added a debug log line in the last commit, only to find out it’s now
logging the same info twice. So removed the double entry and tweaked
the existing once.
In order to fix the failing test in the preceding commit when optional
params are changed from their default "computed" values.
These weren't working well with `HttpHealthCheck.Patch()` because it was
attempting to set all unspecified params to Go's type defaults (eg. 0 for
int64) which the API rejected.
Changing the call to `HttpHealthCheck.Update()` seemed to fix this but it
still didn't allow you to reset a param back to it's default by no longer
specifying it.
Settings defaults like this, which match the Terraform docs, seems like the
best all round solution. Includes two additional tests for the acceptance
tests which verify the params are really getting set correctly.
By first creating a very simple resource that mostly uses the default
values and then changing the two thresholds from their computed defaults.
This currently fails with the following error and will be fixed in a
subsequent commit:
--- FAIL: TestAccComputeHttpHealthCheck_update (5.58s)
testing.go:131: Step 1 error: Error applying: 1 error(s) occurred:
* 1 error(s) occurred:
* 1 error(s) occurred:
* Error patching HttpHealthCheck: googleapi: Error 400: Invalid value for field 'resource.port': '0'. Must be greater than or equal to 1
More details:
Reason: invalid, Message: Invalid value for field 'resource.port': '0'. Must be greater than or equal to 1
Reason: invalid, Message: Invalid value for field 'resource.checkIntervalSec': '0'. Must be greater than or equal to 1
Reason: invalid, Message: Invalid value for field 'resource.timeoutSec': '0'. Must be greater than or equal to 1
Mixture of hard and soft tabs, which isn't picked up by `go fmt` because
it's inside a string. Standardise on hard-tabs since that is what's used
in the rest of the code.
The commit is pretty complete and has a tested/working provisioner for
both SSH and WinRM. There are a few tests, but we maybe need another
few to have better coverage. Docs are also included…
* ctiwald/ct/fix-protocol-problem:
aws: Document the odd protocol = "-1" behavior in security groups.
aws: Fixup structure_test to handle new expandIPPerms behavior.
aws: Add security group acceptance tests for protocol -1 fixes.
aws: error on expndIPPerms(...) if our ports and protocol conflict.
Users can input a limited number of protocol names (e.g. "tcp") as
inputs to network ACL rules, but the API only supports valid protocol
number:
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
Preserve the convenience of protocol names and simultaneously support
numbers by only writing numbers to the state file. Also use numbers
when hashing the rules, to keep everything consistent.
AWS will accept any overly-specific IP/mask combination, such as
10.1.2.2/24, but will store it by its implied network: 10.1.2.0/24.
This results in hashing errors, because the remote API will return
hashing results out of sync with the local configuration file.
Enforce a stricter API rule than AWS. Force users to use valid masks,
and run a quick calculation on their input to discover their intent.
AWS doesn't store ports for -1 protocol rules, thus the read from the
API will always come up with a different hash. Force the user to make a
deliberate port choice when enabling -1 protocol rules. All from_port
and to_port's on these rules must be 0.
AWS includes default rules with all network ACL resources which cannot
be modified by the user. Don't attempt to store them locally or change
them remotely if they are already stored -- it'll consistently result
in hashing problems.
resourceAwsNetworkAclRead swallowed these errors resulting in rules
that never properly updated. Implement an entry-to-maplist function
that'll allow us to write something that Set knows how to read.
If an AutoScalingGroup is in the middle of performing a Scaling
Activity, it cannot be deleted, and yields a ScalingActivityInProgress
error.
Retry the delete for up to 5m so we don't choke on this error. It's
telling us something's in progress, so we'll keep trying until the
scaling activity completed.
On ASG creation, waits for up to 10m for desired_capacity or min_size
healthy nodes to show up in the group before continuing.
With CBD and proper HealthCheck tuning, this allows us guarantee safe
ASG replacement.
* 'master' of github.com:hashicorp/terraform:
provider/aws: detach VPN gateway with proper ID
update CHANGELOG
provider/aws: Update ARN in instanceProfileReadResult
provider/aws: remove placement_group from acctest
core: module targeting
Added support for more complexly images repos such as images on a private registry that are stored as namespace/name
Depends on there being an existing placement group in the account called
"terraform-placement-group" - we'll need to circle back around to cover
this with AccTests after TF gets an `aws_placement_group` resource.
- Users
- Groups
- Roles
- Inline policies for the above three
- Instance profiles
- Managed policies
- Access keys
This is most of the data types provided by IAM. There are a few things
missing, but the functionality here is probably sufficient for 95% of
the cases. Makes a dent in #28.
Ingress and egress rules given a "-1" protocol don't have ports when
Read out of AWS. This results in hashing problems, as a local
config file might contain port declarations AWS can't ever return.
Rather than making ports optional fields, which carries with it a huge
headache trying to distinguish between zero-value attributes (e.g.
'to_port = 0') and attributes that are simply omitted, simply force the
user to opt-in when using the "-1" protocol. If they choose to use it,
they must now specify "0" for both to_port and from_port. Any other
configuration will error.
Joe Topjian