Custom underlying services #16
Conversation
Signed-off-by: Eguzki Astiz Lezaun <[email protected]>
|
There are still some |
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| TODO |
There was a problem hiding this comment.
One potential drawback is that we do not want users to change some settings. From the top of my head, I can think of Authorino spec.clusterWide and authConfigLabelSelectors, which could mean that the user could easily end up with AuthPolicy that will be reconciled by Kuadrant but won't be picked up in Authorino.
There was a problem hiding this comment.
Kuadrant should reconcile those changes from the external services, right? More specifically, when the Authorino CR is (externally) updated and the label selectors are updated, the AuthConfig CR's managed by kuadrant should reconcile to match.
| name: <kuadrant-name> | ||
| namespace: <kuadrant-namespace> | ||
| spec: | ||
| authorinoTargetRef: |
There was a problem hiding this comment.
| authorinoTargetRef: | |
| authorinoRef: |
| authorinoTargetRef: | ||
| name: <authorino-name> | ||
| namespace: <authorino-namespace> | ||
| limitadorTargetRef: |
There was a problem hiding this comment.
| limitadorTargetRef: | |
| limitadorRef: |
|
Updating with my latest changes and handing over to anyone from the team |
|
Superseded by #25 |
Related issue: Kuadrant/kuadrant-operator#164