If a single change fails during the retry, it will be added to a queue.
In the next iteration, changes from this queue will be submitted after
all other changes.
When submitting single changes, they are always submitted as batches of
changes with the same DNS name and ownership relation to avoid
inconsistency between the record created and the TXT records.
Log whenever a target is not able to be parsed as an IP address. This is expected
to occur fairly often (for example, with CNAME targets), but allows more visibility
into how targets are being compared.
NOTE: depending on the number and type of targets, this could be quite noisy.
Previously there was no distinction between an IP address and any other string
when doing a comparison to determine which is "less" when determining which endpoint to actually create.
This explicitly handles IP addresses and will always prefer
them over non-IP addresses when determining which of two targets is less.
Currently, planning instructs to create all records even
those which does not match any zone.
Later, those records will be checked towards the existing
records and filtered whether they match or not a hosted zone.
This causes a problem, at least in the specific case of the Route53
implementation as it always calls the ApplyChanges method, which in its
turn always retrieves all records in all zones.
This causes high pressure on Route53 APIs, for non-necessary actions.
By being able to filter all unmanaged records from the plan, we can
prevent from calling ApplyChanges when nothing has to be done and hence
prevent an unnecessary listing of records.
By doing so, the rate of API calls to AWS Route53 is expected to be
reduced by 2
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.
* First stab at NodePort support. Testing incomplete
* Fix up the unit tests
* Remove some deadcode in the unittests
* gather node ips once and add support for srv records
* Make sure we match gofmt simple
* Move the nodes to the testcase and add a test for clusters that only have internal ip addresses
* Somehow forgot about the weight field in the records
* Add SRV as a supported record type
* Endpoint.Target is now Endpoint.Targets. This is its own type representing mutliple targets for a single DNS name while adding some convenience for sorting and comparing
* Made everything compile and tests run through with the new Endpoint.Targets
* The ingress source can now properly handle multiple target ips per host
* Added custom conflict resolver, to better understand how conflict resolution has to work for me
* My custom conflict resolver behaves a bit different than the PerResource resolver, therefore I needed to modify the expected test result
Removed unnecessary FIXME
* The ingress source now creates CNAME endpoints with multiple targets to let the DNS provider decide how to handle multiple CNAME targets. This could be interesting for weighted targets etc.
* Adopted the expected results to the new way we create endpoints for CNAMEs
* Removed Add method from Targets since manipulating the slice through here is unnecessary complicated and doesn't deliver enough convenience
* Reverted ConflictResolver to the original one. There is some discussing to do what the best way is to handle conflicts
* Added missing documenting comment to IsLess of Targets
* Added documenting comments to Targets,Targets.Same and NewTargets to clarify their intention and usage
* Service source now also generates endpoints with multiple targets
* Service and Ingress source now sort all Targets for every Endpoint to make order of Targets predictable
* Endpoints generated by the Google Cloud DNS provider now also have sorted Targets to make order of Targets predictable
* Modified provider dyn to be able to compile with multi target changes
* Fixed small nitpicks, so my code is acceptable
* Fixed merge method after updating to new Targets. Replacing '!=' with .Same of course needs a boolean negation
* Tests for dyn provider now also use the new Targets instead of Target
* Simplified extractServiceIps as implied by linki to make it more readable
* ref: change service ClusterIP retrieval again
* Added entry to CHANGELOG.md describing the new features contained in this PR
* Make suitableType() be Endpoint method
With this change it becomes possible to work with endpoint
of empty type in packages other than "provider". Also
it seems logical for a smart property getter without side effects
to be a method rather than a function in different package
* Make plan computation work correctly with multi-target domains
* fix drawing
* drop comments
* fix boilerplate header
* fix comment
* fix the bug with empty map
* rework registry to support random lables
* serialize->serializeLabel function rename
* golint for err variable naming
* add additional test
* add tests for current case where one resource can generate multiple endpoints
* make labels have its own type, add serialization as a method
* add comment for exported error
* use greater rather than not equal zero
* update changelog
* Add RecordTTL
* Route53: test for custom TTL
* Fix tests
* Fix remaining tests
* Add ttl when endpoint is created from ingress
* Missed a word
* Fix bad refactoring
* Add ingress custom TTL test
* gofmt
* Satisfy go-lint
* Unshadow `endpoint` in azure provider
* Fix and add an output test
* Add TTL for endpoints generated from service templates
* Take TTL into account when generating update plan
* Tests for TTL change impact on the plan
* Refactor factory method name
* Refactoring
* Run gofmt
* Make endpoint string format look like BIND config
* Update plan and plan_test
* Replace NewEndpointWithTTLValue with NewEndpointWithTTL in aws
* Remove NewEndpointWithTTLValue func
* Update references to TTL
* Remove getTTLValue func
* Handle merge conflict
* Update tests
* Update README, CHANGELOG and documentation
* Run gofmt
* Move getTTLFromAnnotations to a common file
* Refactor getTTLFromAnnotations
* Gofmt
* Add tests for getTTLFromAnnotations
* Trigger build
* Add boilerplate header
* Update README/CHANGELOG according to code review
* Add ttl.md and link it from README
* change CNAME string to endpoint.RecordTypeCNAME
* fix test cases with AWS ALIAS records, these do not behave different in these tests
* ref(source): use testify with mocks in test code
* fix: re-introduce NewMockSource for convenience
* fix: avoid circular dependency
* ref: increase usage of testify
* chore: vendor testify as a dependency
* fix(*): cleanup testify expectations
