Ingress update resets values incorrectly

[joshblakeley]

From ticket 10558 - quite a bad bug. Some more unit tests to cover the templating are needed.

The Ingress Controller correctly picks up updates to annotations, based on the logs:

level=info msg="setting bool value: proxy.preserve_host_header" app=tk8s mod=processor 
level=info msg="setting string value: proxy.target_url" app=tk8s mod=processor 

However a few issues remain:

1. Not all annotations work. Setting string.service.tyk.io/proxy.listen_path: "/petstore/" does not set it correctly in the API Definition. Even though we see it detected by the controller in the logs.

I looked in the docs to see whether there was a documented limitation but found nothing. Also, if there were I would expect it to be reflected in the controller logs.

I need this to be able to control the proxying path. I tried with slug but as you said, this cannot be done at the moment. This was the other option I found. How could I configure that?

2. When modifying one or multiple annotations, for some reason the values are reset to their default and not the updated value. Again, logs show the controller picked up the change but the end result is not the expected one.

"Demo":

A. Deploy ingress with following annotations

annotations: 
kubernetes.io/ingress.class: tyk 
bool.service.tyk.io/proxy.preserve_host_header: "true" 
string.service.tyk.io/proxy.target_url: "http://httpbin.org/ip" 

-> Result: API Definition has provided values for the set fields.

B. Modify annotations of ingress and apply it

annotations: 
kubernetes.io/ingress.class: tyk 
bool.service.tyk.io/proxy.preserve_host_header: "true" 
string.service.tyk.io/proxy.target_url: "http://httpbin.org" # change here 

Result: Both proxy.preserve_host_header and proxy.target_url are somehow set back to their default value. In my case false and http://petstore.test:80 respectively.

[joshblakeley]

I suspect this was already fixed by #41 but added a more explicit test to confirm

[nerdydread]

Annotation updates are picked up by the ingress controller and can be seen in the logs however, they are not actually being applied to the API definitions themselves. Will be addressing this item as part of K8 controller revamp.