-
Notifications
You must be signed in to change notification settings - Fork 170
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
THREESCALE-8508 - /admin/api/account/proxy_configs endpoint for configuration loading #1352
Conversation
a76258a
to
bf8b6e8
Compare
-- http://${THREESCALE_PORTAL_ENDPOINT}/admin/api/account/proxy_configs/<env>.json?host=host&version=version | ||
local function configuration_endpoint_params(env, host, portal_endpoint_path) | ||
local version = resty_env.get( | ||
format('APICAST_SERVICE_%s_CONFIGURATION_VERSION', service_id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where is this service_id
coming from?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you are right @eguzki we don't have that info there, I missed it, and even if we did, it wouldn't be the correct logic to apply because the version of a single service would apply to all services returned by the API endpoint. This means when the APICAST_SERVICE_%s_CONFIGURATION_VERSION
env var is set we should use the old logic and endpoints because we need to retrieve each service's configuration individually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
apparently, that environment variable (for configuring a specific service version) only works when specific conditions are met:
- THREESCALE_PORTAL_ENDPOINT points to an admin portal, and
- APICAST_LOAD_SERVICES_WHEN_NEEDED is not configured
Because in order to fetch a specific version it's necessary to load services individually (so that the version can be specified for each service configuration URL). And this is not possible via master or the new services endpoint. This is currently the behavior we have also in master and even in previous stable versions.
For now, I updated the logic to fall back to the "old" endpoint and load services one by one when APICAST_SERVICE_%s_CONFIGURATION_VERSION
is configured (and THREESCALE_PORTAL_ENDPOINT
is an admin portal), and I added logs to notify when services will be loaded this way, individually. This means we would preserve the current behaviour when the version env var is set.
I added 2 tests too.
We need to verify and confirm that this is the best way to handle things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added the same "exceptions" for APICAST_SERVICES_LIST
and APICAST_SERVICES_FILTER_BY_URL
env vars.
Code looks ok. Also tests. Just to verify: APIcast no longer will request proxy configuration for a given service ID. When "lazy" configuration, the endpoint will have a query param for the given "host". Right? Question: what if two services have the same host? |
For managed APIcast deployment (on-prem releases), the THREESCALE_PORTAL_ENDPOINT env var has path configured to This is still valid or should be changed? |
That's right. If multiple services have the same host they will all be loaded in APIcast at once and treated as usual. |
That's fine @eguzki, since it points to master, this PR should have no effect on gateways configured that way. |
9add291
to
851a1d6
Compare
45d16f1
to
eb006ce
Compare
Is this lost in the ether? |
No @secretsurf sorry I am supposed to be reviewing and testing this but too many other burning issues I didn't manage to get to this yet. |
One thing I concern about this is the paginated endpoint. From the description in the issue
and I do not remember to see any pagination implementation. Maybe it was done after my initial review |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this PR is missing documentation because of how it behaves with different env vars. Without that documentation it will result in users run into issues as they won't understand what is the expected behaviour. Also a decision needs to be made whether we want to split the implementation into 2 iterations as this PR will not support >500 services but it does introduce support for >500 versions of a service's proxy config object.
33fab9f
to
7edeb7d
Compare
7edeb7d
to
2002f9f
Compare
2002f9f
to
7c3c460
Compare
@pehala @thomasmaas this PR is ready for review |
leaving pagination implementation for a (soon) coming PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a breaking change, can you enable the old behaviour? Does enabling the old behaviour even make sense?
Basically, we are making an opt-in behavior the default one. Opt-in is no longer needed, hence removal of env var. |
Right, and is there a option to opt-out? Does it even make sense to opt-out or is the new behaviour simply superior? |
For me it does not make sense to opt-out. But if for whatever reason there is a need to opt-out from the current default behavior and get all services and ask for proxy config for each service, there are ways.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not have enough knowledge to do a full-on technical review. However, the proposed changes make sense to me.
This PR uses
/admin/api/account/proxy_configs
for the standard configuration loading process, as the default endpoint that APIcast will attempt to fetch the configuration from when the portal endpoint is provided without a path (admin portal endpoint).With this proposed implementation, APICAST_LOAD_SERVICES_WHEN_NEEDED is deprecated and the configuration is fetched "when needed" by default whenever possible, with the following logic:
http://${THREESCALE_PORTAL_ENDPOINT}/admin/api/account/proxy_configs/<env>.json?version=version
(i.e. all services from proxy_configs endpoint). Using the new endpoint now one request is enough, no need to loop through all services.http://${THREESCALE_PORTAL_ENDPOINT}/admin/api/account/proxy_configs/<env>.json?host=host&version=version
(i.e. services that matchhost
from proxy_configs endpoint). This matches the current behaviour when APICAST_LOAD_SERVICES_WHEN_NEEDED is enabled.http://${THREESCALE_PORTAL_ENDPOINT}/<env>.json
(i.e. all services from master endpoint). Same as the current behaviour.http://${THREESCALE_PORTAL_ENDPOINT}/<env>.json?host=host
(i.e. services that matchhost
from master endpoint). Same as the current behaviour.i.e. the path appended to ${THREESCALE_PORTAL_ENDPOINT} is:
Update : When any of the following environment variables exist, the gateway will load services one by one.
APICAST_SERVICE_%s_CONFIGURATION_VERSION
APICAST_SERVICES_LIST
APICAST_SERVICES_FILTER_BY_URL
These environment variables are not compatible when pointing to master (when a custom path is provided). Added a check to log error when that incompatible scenario happens.
update:
APICAST_SERVICES_FILTER_BY_URL
andAPICAST_SERVICES_LIST
were added as incompatible with loading config with the new endpoint. Actually, those env vars are compatible with all loading modes. This issue will be fixed in #1397