feat(license) add expired license behavior #5936
Draft
+155
−12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it:
Add new rules for the license agent when the license is expired. The agent will use its initial polling period and disregard
updated_at
when its cached license is expired.Add an expired license check helper.
Which issue this PR fixes:
Seeks to fix expired license status quickly, because we want to get out of that state if we're in it. This situation generally should not occur, but could if the controller were unable to talk to Konnect around the same time as its cached license was expiring.
The
updated_at
behavior is somewhat odd but based on an actual situation where upstream essentially lied about the date and provided a current license with an olderupdated_at
than another expired license it had previously served. There's no use to providing an expired license to the gateway, so we may as well always update cache until we get something that's not expired.Special notes for your reviewer:
Per comments, the Kong license APIs feature JSON blobs embedded in JSON objects, which is annoying. We can't really properly retrieve license expiration information, though we can probably reasonably expect that it is available at the indicated path. If that expectation breaks, this takes a conservative approach and reverts to expiration-unaware behavior (it updates at the standard interval and relies on
updated_at
).The update frequency change is probably always warranted. The change to have expiration supersede
updated_at
were requested, but I'm less sure of them. There are some unknowns about the incident that suggest they're not actually warranted. See chat discussion for further details.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