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 https://github.com/janus-idp/operator/issues/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.
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:
Proposals:
There are 2 reasonable way to simplify it, we can consider both (one does not exclude other):