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
{{ message }}
This repository has been archived by the owner on Aug 19, 2024. It is now read-only.
Context: it is possible to define any deployment configuration redefining deployment.xml in:
default configuration (cluster scope)
raw CR configuration (instance scope)
but for the time user have to define the whole deployment.yaml manifest which is some big
Proposals:
There are 2 reasonable way to simplify it, we can consider both (one does not exclude other):
Just to address this problem: add necessary sidecar(s) to default deployment.yaml but consider it disabled by default (operator will exclude all but mandatory backstage and init container runtime) and make an option in CR to enable sidecars, e g: Backstage.spec.enableSidecars=true|[false]
Generic solution, which could address other problems requiring "slight changes" of configuration (like this Permission issues on mounted Volumes for RHDH container #254 ): supporting patches for default/raw configuration. This way user/admin will be able to add any missing pieces for particular cluster/instance with proposing merging patch. Technical Proposal will come in other issue.
The text was updated successfully, but these errors were encountered:
Simplify supporting adding sidecar containers to Backstage deployment.
Example: adding OAuth2 Proxy for Keyclock support as described in https://janus-idp.io/blog/2023/01/17/enabling-keycloak-authentication-in-backstage .
Context: it is possible to define any deployment configuration redefining deployment.xml in:
but for the time user have to define the whole deployment.yaml manifest which is some big
Proposals:
There are 2 reasonable way to simplify it, we can consider both (one does not exclude other):
The text was updated successfully, but these errors were encountered: