-
Notifications
You must be signed in to change notification settings - Fork 591
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
Add --publish-status-address to 2.x #1509
Conversation
Licenses differ between commit 3ef1829afcc6b6ba47a72d52f50559cfb976f9b7 and base:
|
Codecov Report
@@ Coverage Diff @@
## next #1509 +/- ##
==========================================
- Coverage 51.52% 51.36% -0.17%
==========================================
Files 91 91
Lines 6292 6300 +8
==========================================
- Hits 3242 3236 -6
- Misses 2757 2770 +13
- Partials 293 294 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
This reverts commit 2fae8d2. Restore the --publish-status-address flag and associated logic in the status updater. This flag takes a user-provided IP address and uses it instead of attempting to determine an address from the proxy Service, for cases where that information is not available or does not reflect the effective external address of the proxy.
- Finalize the 2.0.0-alpha.2 date. - Create the 2.0.0-alpha.3 section. - Add status features to 2.0.0-alpha.3.
b2e67f5
to
cb4f256
Compare
Travis, thanks for taking care of this and clarifying that PublishStatusAddress can be read when a valid proxy public IP is not available . 💯 Questions:
thanks |
No, it's the proxy IP, not the admin API IP. In either case, sending something through an external address when an internal path exists is usually not desired: it likely traverses a path with less bandwidth/more latency and may result in ingress/egress charges from a cloud provider.
It's an unknown network endpoint that the user promises will ultimately route to the proxy. This flag is intended specifically for cases where you cannot retrieve the address(es) from Kubernetes, e.g. an independent load balancer that points to the proxy's NodePort. |
What this PR does / why we need it:
This was originally added to #1451, but later removed. I thought that removal had been reverted, but it wasn't, and I got confused in the PR history and missed that before it went in.
Per #1305 we do want to include this in 2.x for 1.x flag parity. The flag is useful when IP information is missing from the publish service (e.g. bare metal clusters) or does not reflect the true external address of the proxy (e.g. when you chain proxies and have something else in front of Kong).
Lastly, this updates
--publish-status-address
to use a StringSlice, following the same logic as #1496. Note that 1.x--publish-status-address
originally supported only a single IP, but we may as well allow multiple, as it's compatible.Which issue this PR fixes:
fixes #1305 in conjunction with #1451
Special notes for your reviewer:
The reverted commit also included an additional new feature for deriving the Kong admin API URL from its Service, instead of providing it directly in
--kong-admin-url
. Per my comments in #1486 (which also includes the same feature) this isn't ready for merge yet, as it breaks some existing functionality (namely HTTPS). The admin API doesn't factor into status information at all, and it should be raised in a separate PR if we wish to include it.Edit: this actually was already reverted... somewhere in history. It's in the reverted commit, but not in the diff here, so the above can be ignored for the context here.
This updates the changelog to reflect the 2.0.0-alpha.2 release. We forgot to do that for the actual release.
PR Readiness Checklist:
Complete these before marking the PR as
ready to review
:CHANGELOG.md
release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR