[BUGFIX] Plugins should be valid when StatusOK is returned by the kong API #81
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.
When go-kong calls the kong API
schemas/plugins/validate
endpoint as part ofValidate
, it only returnstrue
if the statusCode isStatusCreated
but the kong API returns a 200 (StatusOK
). As far as I can tell, earlier versions of the kong API returned a 200 as well.This means that when a valid plugin is checked by the validatingwebhook in the kong-ingress-controller the webhook will block the resource from being created. It's also hard to understand why the webhook blocked it as there is no error returned back (rightfully so in this case as the plugin is valid). For example it results in an error like this:
It seems possible that when this code was ported out of the kong-ingress-controller it tried copying some of the same logic over (which did include a check for status == 201) and maybe why this came about. This PR in the kong-ingress-controller could help explain why that logic exist here and shows that the old logic allowed all status codes to be considered valid.
Again I've not been able to find a reference in the existing kong API (or previous versions) that would indicate a 201 was ever returned as a result of this API call, but I've left it here in case there is some context that I've missed somewhere.