When AAAA multi-target / dual stack support was
added via #2461 it broke ownership of domains across
different clusters with different ingress records types.
For example if 2 clusters manage the same zone,
1 cluster uses A records and the other uses CNAME
records, when each record type is treated as a separate
planning record, it will cause ownership to bounce back
and forth and records to be constantly created and
deleted.
This change updates the planner to keep track of multiple
current records for a domain. This allows for A and AAAA
records to exist for a domain while allowing record type
changes.
The planner will ignore desired records for a domain that
represent conflicting record types allowed by RFC 1034 3.6.2.
For example if the desired records for a domain contains
a CNAME record plus any other record type no changes for
that domain will be planned.
The planner now contains an owned record filter provided
by the registry. This allows the planner to accurately plan
create updates when there are record type changes between
the current and desired endpoints. Without this filter the
planner could add create changes for domains not owned
by the controller.
When AAAA multi-target / dual stack support was
added via #2461 it broke ownership of domains across
different clusters with different ingress records types.
For example if 2 clusters manage the same zone,
1 cluster uses A records and the other uses CNAME
records, when each record type is treated as a separate
planning record, it will cause ownership to bounce back
and forth and records to be constantly created and
deleted.
This change updates the planner to keep track of multiple
current records for a domain. This allows for A and AAAA
records to exist for a domain while allowing record type
changes.
The planner will ignore desired records for a domain that
represent conflicting record types allowed by RFC 1034 3.6.2.
For example if the desired records for a domain contains
a CNAME record plus any other record type no changes for
that domain will be planned.
The planner now contains an owned record filter provided
by the registry. This allows the planner to accurately plan
create updates when there are record type changes between
the current and desired endpoints. Without this filter the
planner could add create changes for domains not owned
by the controller.
This change tries to remove part of the logic added in 50f196c0db.
The forceUpdate strategy relies on existing code of the planner to migrate TXT records to the new format,
being the main goal to avoid conflicts during apply.
Signed-off-by: Matias Charriere <matias@giantswarm.io>
shouldUpdateProviderSpecific seems to be iterating over just the current properties that were previously set, not taking into consideration for planning changes when additional ProviderSpecific properties were just set.
The previous code version only iterates over current ProviderSpecific properties. This new version iterates over desired properties, including those that were just set.
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
* adds flag to opt in for NS records management
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* go fmt
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* goimports
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* fix more tests
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* go fmt again
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* fix test
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* more tests
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* make ordering of managed records consistent
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* fix flag
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* adds tests for shouldUpdateProviderSpecific
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* move AWS health to where it belongs
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* add test that breaks things
Signed-off-by: Raffaele Di Fazio <difazio.raffaele@gmail.com>
* adds adjustendpoints method
Signed-off-by: Raffaele Di Fazio <raffo@github.com>
* fix controller
Signed-off-by: Raffaele Di Fazio <raffo@github.com>
* actually pass the provider where needed
Signed-off-by: Raffaele Di Fazio <raffo@github.com>
* OMG goland do your go fmt thing
Signed-off-by: Raffaele Di Fazio <raffo@github.com>
* use registry as proxy
Signed-off-by: Raffaele Di Fazio <raffo@github.com>
* make linter happy
Signed-off-by: Raffaele Di Fazio <raffo@github.com>
* change AdjustEndpoints signature
Signed-off-by: Raffaele Di Fazio <raffo@github.com>
* fix typo
Signed-off-by: Raffaele Di Fazio <raffo@github.com>
* actually use adjusted endpoints
Signed-off-by: Raffaele Di Fazio <raffo@github.com>
* revert cloudflare change
Signed-off-by: Raffaele Di Fazio <raffo@github.com>
* Update provider/cloudflare/cloudflare.go
Co-authored-by: Nick Jüttner <nick@juni.io>
Co-authored-by: Nick Jüttner <nick@juni.io>
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.
