You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the PR #48 is merged, the kuadrant as a system will not be working unless the namespace where kuadrant is installed is kuadrant-system. This issue comes from the fact that the policy controller are no longer deployed as components of a kuadrant instance. Instead, the controllers live at the kuadrant's operator pod and they are up&running even if there is no kuadrant instance running in the cluster.
The very source issue of this "side effect" is the design about how backend services were wired with the Ratelimit/Auth policies. As it was designed, it allowed kuadrant instance to be installed in any namespace, however, the design only allowed one kuadrant instance to be running in the cluster. When the controllers were moved to the operator's pod, one of the design's requirements (the controllers know at deploy time with env vars where the kuadrant's backend services live) was unmet, thus causing the issue.
This issue is to track the fix, as it seems desirable that kuadrant can be installed in any namespace.
Related but not in the scope of this issue is the decision about whether kuadrant supports multiple instances in a single cluster or not. That would require a definition of how policies are wired to the backend services (limitador for the rate limiting and authorino for the authN/authZ services). Once it is clear how policies are linked to the backend services, the fix of this issue should not be hard.
The text was updated successfully, but these errors were encountered:
eguzki
changed the title
Wire policies with backend services
Kuadrant instance can be installed in any namespace
Nov 4, 2022
When the PR #48 is merged, the kuadrant as a system will not be working unless the namespace where kuadrant is installed is
kuadrant-system
. This issue comes from the fact that the policy controller are no longer deployed as components of a kuadrant instance. Instead, the controllers live at the kuadrant's operator pod and they are up&running even if there is no kuadrant instance running in the cluster.The very source issue of this "side effect" is the design about how backend services were wired with the Ratelimit/Auth policies. As it was designed, it allowed kuadrant instance to be installed in any namespace, however, the design only allowed one kuadrant instance to be running in the cluster. When the controllers were moved to the operator's pod, one of the design's requirements (the controllers know at deploy time with env vars where the kuadrant's backend services live) was unmet, thus causing the issue.
This issue is to track the fix, as it seems desirable that kuadrant can be installed in any namespace.
Related but not in the scope of this issue is the decision about whether kuadrant supports multiple instances in a single cluster or not. That would require a definition of how policies are wired to the backend services (limitador for the rate limiting and authorino for the authN/authZ services). Once it is clear how policies are linked to the backend services, the fix of this issue should not be hard.
The text was updated successfully, but these errors were encountered: