Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ingress target annotation should set, not append #318

Merged

Conversation

claytono
Copy link
Contributor

@claytono claytono commented Aug 11, 2017

If the user has specified a target for the ingress, treat that as
overriding any endpoints already set on the ingress, even if that list
is not empty. This allows overriding the IP address or hostname set
when using a service like kube-keepalived-vip.

This is related to #312

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Aug 11, 2017
@claytono
Copy link
Contributor Author

/assign hjacobs

@hjacobs
Copy link
Contributor

hjacobs commented Aug 12, 2017

@ClaytonONeill please also change the logic when FQDN template is used (endpointsFromTemplate) to make it consistent. Otherwise LGTM.

@claytono claytono force-pushed the fix-ingress-annotation-appending branch from ee783d6 to 29d6f86 Compare August 12, 2017 17:22
@claytono
Copy link
Contributor Author

@hjacobs Thanks for catching that. Should be fixed in both places now. Not sure how I overlooked that.

@ideahitme ideahitme self-requested a review August 13, 2017 08:16
@hjacobs
Copy link
Contributor

hjacobs commented Aug 14, 2017

@ideahitme could you have a quick look (also to get familiar with this feature). LGTM, but I already overlooked something the last time 😏

Copy link

@ideahitme ideahitme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor improvements can be done here

@@ -152,7 +160,11 @@ func endpointsFromIngress(ing *v1beta1.Ingress) []*endpoint.Endpoint {
continue
}

endpoints = addEndpointsFromTargetAnnotation(ing, rule.Host, endpoints)
endpoints = getEndpointsFromTargetAnnotation(ing, rule.Host)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not entirely sure about this, so this basically ignores all but lastrules.host and generate endpoint from it. Why not generate an endpoint for each of the hosts found ?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO getEndpointsFromTargetAnnotation should be called from Endpoint() method above:

  1. Try to generate endpoint from target annotation key, if none:
  2. Try to generate endpoint from ingress status field, if none:
  3. Try to generate endpoint from template

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ideahitme My thought was to move it to be called from Endpoint also, but then that leads to duplication of the code that loops over the rules gathering hosts.

As far as the call to it in the endpointsFromTemplate function, I'm not sure. If the consensus is to change that I'll be glad to do it, but I'd rather not have this fix get bogged down on something unrelated.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ClaytonONeill it is okay, it was just a suggestion on to improve overall code structure - which can be done in subsequent PR. Otherwise this pull request looks okay to me. If no objections I will have this merged /cc @linki

Copy link

@ideahitme ideahitme Aug 15, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ClaytonONeill and also my first comment above (regarding ignoring all but last rule.host values), is that intentional ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I think that's accidental. I'll take a look at fixing that and get this updated if I'm correct.

@@ -129,7 +133,11 @@ func (sc *ingressSource) endpointsFromTemplate(ing *v1beta1.Ingress) ([]*endpoin

hostname := buf.String()

endpoints = addEndpointsFromTargetAnnotation(ing, hostname, endpoints)
endpoints = getEndpointsFromTargetAnnotation(ing, hostname)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this does not belong here, endpointsFromTemplate is called only as a last resort to generate an endpoint, i.e. there is no target annotation

@claytono claytono force-pushed the fix-ingress-annotation-appending branch from 29d6f86 to 0ce65b1 Compare August 16, 2017 02:40
@claytono
Copy link
Contributor Author

@ideahitme I think the latest update should fix the issue you identified.

@ideahitme
Copy link

@ClaytonONeill please update the changelog and good to be merged from my side

@linki
Copy link
Member

linki commented Aug 16, 2017

@ideahitme @ClaytonONeill lgtm

If the user has specified a target for the ingress, treat that as
overriding any endpoints already set on the ingress, even if that list
is not empty.  This allows overriding the IP address or hostname set
when using a service like kube-keepalived-vip.
@claytono claytono force-pushed the fix-ingress-annotation-appending branch from 0ce65b1 to a934bcd Compare August 17, 2017 13:02
@claytono
Copy link
Contributor Author

@ideahitme I wasn't 100% sure about the changelog, so I updated it as if it were a new release. If you want something different let me know and I can get it updated to match.

@hjacobs hjacobs merged commit ea4cbfe into kubernetes-sigs:master Aug 17, 2017
@hjacobs
Copy link
Contributor

hjacobs commented Aug 17, 2017

@james-masson
Copy link

This seems to be non-functional on Google with v0.4.4

time="2017-09-25T10:28:20Z" level=debug msg="Endpoints generated from ingress: shared-services/nginx: [testconsul.<domain> -> helm-dev.<domain> (type "")]"
time="2017-09-25T10:28:20Z" level=info msg="Add records: testconsul.<domain>. CNAME [helm-dev.<domain>.]"
time="2017-09-25T10:28:20Z" level=info msg="Add records: testconsul.<domain>. TXT ["heritage=external-dns,external-dns/owner=helm-dev"]"
time="2017-09-25T10:28:20Z" level=error msg="googleapi: Error 400: The resource record set 'entity.change.additions[0]' is invalid because the DNS name 'testconsul.<domain>.' may have either one CNAME resource record set or resource record sets of other types, but not both.
More details:
Reason: cnameResourceRecordSetConflict, Message: The resource record set 'entity.change.additions[0]' is invalid because the DNS name 'testconsul.<domain>.' may have either one CNAME resource record set or resource record sets of other types, but not both.
Reason: cnameResourceRecordSetConflict, Message: The resource record set 'entity.change.additions[1]' is invalid because the DNS name 'testconsul.<domain>.' may have either one CNAME resource record set or resource record sets of other types, but not both.
"

@claytono
Copy link
Contributor Author

@james-masson Does it work normally without target annotations? I saw the same problem on Route53 w/AWS when using a hostname for the target annotation, but ended up switching back to IP based target annotations for other reasons. I assumed this wasn't a target annotation specific issue at that time.

@james-masson
Copy link

Hmm. I think I put the wrong log in the issue - or perhaps the right log in the wrong issue.

I fixed that error with "txt-prefix" - as it's a CNAME/TXT conflict - nothing to do with this PR.

Apologies for the noise...

ffledgling pushed a commit to ffledgling/external-dns that referenced this pull request Jan 18, 2018
If the user has specified a target for the ingress, treat that as
overriding any endpoints already set on the ingress, even if that list
is not empty.  This allows overriding the IP address or hostname set
when using a service like kube-keepalived-vip.
lou-lan pushed a commit to lou-lan/external-dns that referenced this pull request May 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants