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.
Route 53 records were silently erroring out when saving the records returned
from AWS, because they weren't being presented as an array of strings like we
expected.
This is necessary to support creating parameter groups with parameters
that require a reboot, since the RDS API will return an error when
attempting to set those parameters with ApplyMethod "immediate".
There was an error in the goamz package the prevented updating the
availability zones correctly. So PR #181 should be merged before this
one can be merged…
By using a set for the availability zones, you can use things like
`availability_zones = ["${aws_instance.web.*.availability_zone}"]`
where is very likely multiple of the same zones will be added to the
set. If you use a list here, the list will say it’s changed (even if
you add the same zone) which will force a new resource.
Prior to this, the diff only contained changed set elements. The issue
with this is that `getSet`, the internal function that reads a set from
the ResourceData, expects that each level (state, config, diff, etc.)
has the _full set_ information. This change was done to fix merging
issues.
Because of this, we need to make sure the full set is visible in the
diff.
/cc @pearkes - A few things here:
First, this fixes the issue you mentioned to be in chat. Basically: if
there are no security groups, don't put it into flatten, because flatten
will include a "key.#" = "0".
Next, I transformed your test into a "table-driven" test which are really
nice to write and maintain. Basically, as you find bugs or edge cases, you can
just add to the table and you get the test for free. I recommend these
whereever you have a pure input to output sort of data transformation
function.
Christopher Tiwald