This moves `domain_filter.go` to the `endpoint` package to make it
possible to filter and exclude record names in
`plan.filterRecordsForPlan()` so it does not have to be implemented in
every single provider.
Because some providers access `DomainFilter.filters` directly it had to
be exported.
This adds support for all AWS Route53 routing policies, namely:
* simple (default)
* weighted
* latency
* failover
* geolocation
* multi value answer
These routing policies allow to create multiple records with the same
name, but different "SetIdentifiers". Therefor, as a prerequisite for
implementing support for above routing policies, there is a new
"abstraction layer" added that handles this SetIdentifier by adding a
new attribute in the Endpoint struct and adding another level in the
plan table.
Useful when the private/public zones are named the same but a problem happens in one of them
Additionally adds info about which Hosted Zone AWS Batch errors are happening in
```
level=error msg="InvalidChangeBatch: [Tried to create resource record set [name=woof.service.example.com., type=CNAME, set-identifier=legacy] but it already exists, Tried to create resource record set [name=best.service.example.com., type=CNAME, set-identifier=legacy] but it already exists, Tried to create resource record set [name=better.service.example.com., type=CNAME, set-identifier=legacy] but it already exists, Tried to create resource record set [name=my.service.example.com., type=CNAME, set-identifier=legacy] but it already exists]\n\tstatus code: 400, request id: XXX-XXX-XXX-XX"
```
The controller will retrieve all the endpoints at the beginning of its
loop. When changes need to be applied, the provider may need to query
the endpoints again. Allow the provider to skip the queries if its data was
cached.
number of retries that API calls will attempt before giving up.
This somewhat mitigates the issues discussed in #484 by allowing
the current sync attempt to complete vs. failing and starting anew.
Defaults to 3, which is what the aws-sdk-go defaults to where not
specified.
Signed-off-by: Joe Hohertz <joe@viafoura.com>
This is to add two new tests which will cover the new logic where the
submit route53 changes function can error if any one of the updates
fails for any given batch in any given zone. Additionally, there is now
a test to check that the application does not try and create a set of
entries if the total number of changes associated with a given name is
greater than the total number of allowed changes per batch.
This is to change the way batching works when using the aws provider.
Originally, batching would take the first n records you want to update
and perform the desired actions on those records as part of a sync. It
would then wait for the configured sync period and take the first n
records again and sync them. The issue with this is that when you are
using the TXT registry with a custom prefix, the updates can sync a TXT
record and not the accompanying A/CNAME record. This causes external-dns
to get out of sync with what is created and what the current state
actually is. This update uses the same idea of batching, however, rather
than stopping after the first batch until the next run, batching will
now have a separate batch interval which controls the interval between
each batch in the same sync period. This allows external-dns to fully
sync with route53 as part of each sync and can then know that the state
is complete.
Fixes https://github.com/kubernetes-incubator/external-dns/issues/679
This is to add a new `--aws-evaluate-target-health` which allows the
user to override the default EvaluateTargetHealth value (currently set
to `true`) when creating AWS Route53 ALIAS records. To disable, pass
`--no-aws-evaluate-target-health` as outlined in the help page.
Closes https://github.com/kubernetes-incubator/external-dns/issues/627
* Create `NewAWSProvider` with `AWSConfig` struct
Rather than calling `NewAWSProvider` with a list of objects, you will
now call it using a new `AWSConfig` struct. This allows for clearer
declarations of variables which becomes even more important as more
variables are added.
* Add `aws-max-change-count` flag
Adding a new `aws-max-change-count` flag to override the default max
change count on the aws provider.
Included updated tests with a new `defaultMaxChangeCount` constant and
tests for setting the value as a flag and as an environment variable.
* Update CHANGELOG.md
Updating CHANGELOG.md with 'Add aws max change count flag' PR.
