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)
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.
* 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.
Dave Cunningham