I’ve opened up a PR which fixes the problems with persistence in the headless chart. However, it still behaves in a way that seems unusable so I’m assuming something is misconfigured or I have a misunderstanding about how it’s supposed to be used.
When creating APIs using the REST API (POST to /tyk/apis) the resulting api object is written to the the app_path as a json file. However, using the list apis endpoint (GET to /tyk/apis) won’t show that API until you send a SIGUSR2 signal to the gateway to request a config reload. However, sending that signal causes the pod to restart which creates a service outage. Additionally, the restart is considered a crash by Kubernetes and causes a CrashLoopBackoff state further extending the outage.
Every part of Tyk headless seems to have major usability problems with state persistence and state consistency. Am I missing something here?
Thanks for the reply. Does this mean I have to call the hot-reload API even after using the API to make a change? How does this work with the operator which is supposed to automatically sync state with Ingress definitions? I don’t see any hot reload API calls in the operator source code:
Thanks for the clarification. My intuition is that new users will expect read-after-write consistency with regular CRUD calls so I would suggest making it very clear in API documentation that a hot reload call is required.