Use backstage-operator to install backstage

[masayag]

The PR changes the installation method of Janus-IDP from helm-based to an operator-based.
The configuration for backstage is split between several configmaps according to the sections in app-config.

[masayag]

@jianrongzhang89 can you have a look and see if this is the correct way to go?
Specifically, I'm trying to figure out if using the operator, there is also community catalog operator and if there is a need to explicitly create the Backstage kind (as in this sample https://github.com/janus-idp/operator/blob/72962ea8d6f37226142d7609e9087c486624a622/config/samples/_v1alpha1_backstage.yaml#L2)

[jianrongzhang89]

@jianrongzhang89 can you have a look and see if this is the correct way to go? Specifically, I'm trying to figure out if using the operator, there is also community catalog operator and if there is a need to explicitly create the Backstage kind (as in this sample https://github.com/janus-idp/operator/blob/72962ea8d6f37226142d7609e9087c486624a622/config/samples/_v1alpha1_backstage.yaml#L2)

When the RHDH operator is released, it will be a certified Red Hat operator. It will NOT be released as an community operator.

[jianrongzhang89]

@masayag I tried to install the chart based on the instruction but got error:
helm install orchestrator orchestrator
--set "backstage.upstream.backstage.appConfig.integrations.github[0].host"=github.com
--set "backstage.upstream.backstage.appConfig.integrations.github[0].token"=$GITHUB_TOKEN

Error: INSTALLATION FAILED: no SonataFlowPlatform with the name "sonataflow-platform" found

[masayag]

@masayag I tried to install the chart based on the instruction but got error: helm install orchestrator orchestrator --set "backstage.upstream.backstage.appConfig.integrations.github[0].host"=github.com --set "backstage.upstream.backstage.appConfig.integrations.github[0].token"=$GITHUB_TOKEN

Error: INSTALLATION FAILED: no SonataFlowPlatform with the name "sonataflow-platform" found

@jianrongzhang89 just to make sure I'm reproducing the same setup, did you create the DB before?

[jianrongzhang89]

@masayag I tried to install the chart based on the instruction but got error: helm install orchestrator orchestrator --set "backstage.upstream.backstage.appConfig.integrations.github[0].host"=github.com --set "backstage.upstream.backstage.appConfig.integrations.github[0].token"=$GITHUB_TOKEN
Error: INSTALLATION FAILED: no SonataFlowPlatform with the name "sonataflow-platform" found

@jianrongzhang89 just to make sure I'm reproducing the same setup, did you create the DB before?

Yes the DB was created. Did you test the PR on a fresh cluster?

[masayag]

@masayag I tried to install the chart based on the instruction but got error: helm install orchestrator orchestrator --set "backstage.upstream.backstage.appConfig.integrations.github[0].host"=github.com --set "backstage.upstream.backstage.appConfig.integrations.github[0].token"=$GITHUB_TOKEN
Error: INSTALLATION FAILED: no SonataFlowPlatform with the name "sonataflow-platform" found

@jianrongzhang89 just to make sure I'm reproducing the same setup, did you create the DB before?

Yes the DB was created. Did you test the PR on a fresh cluster?

not on a fresh cluster. but made sure to clean the resources. I'll try on a fresh one.

[jianrongzhang89]

@masayag I tried to install the chart based on the instruction but got error: helm install orchestrator orchestrator --set "backstage.upstream.backstage.appConfig.integrations.github[0].host"=github.com --set "backstage.upstream.backstage.appConfig.integrations.github[0].token"=$GITHUB_TOKEN
Error: INSTALLATION FAILED: no SonataFlowPlatform with the name "sonataflow-platform" found

@jianrongzhang89 just to make sure I'm reproducing the same setup, did you create the DB before?

Yes the DB was created. Did you test the PR on a fresh cluster?

not on a fresh cluster. but made sure to clean the resources. I'll try on a fresh one.

If you test on an existing cluster, make sure you remove all related CRDs before rerun your test. Note that when an operator is undeployed, the CRDs remain in the cluster by default.

[jianrongzhang89]

@jianrongzhang89 can you have a look and see if this is the correct way to go? Specifically, I'm trying to figure out if using the operator, there is also community catalog operator and if there is a need to explicitly create the Backstage kind (as in this sample https://github.com/janus-idp/operator/blob/72962ea8d6f37226142d7609e9087c486624a622/config/samples/_v1alpha1_backstage.yaml#L2)

Yes, you will need to create a RHDH Backstage custom resource (after the operator is deployed) in order to deploy Backstage.

[masayag]

@jianrongzhang89 can you have a look and see if this is the correct way to go? Specifically, I'm trying to figure out if using the operator, there is also community catalog operator and if there is a need to explicitly create the Backstage kind (as in this sample https://github.com/janus-idp/operator/blob/72962ea8d6f37226142d7609e9087c486624a622/config/samples/_v1alpha1_backstage.yaml#L2)

Yes, you will need to create a RHDH Backstage custom resource (after the operator is deployed) in order to deploy Backstage.

With the updated version of the chart I'm able to get the backstage instance to start, but it fails to load the orchestrator and the notification plugins. I'll check this earliest next week.

However, one thing I could bypass is the environment set always to production, no matter what type of method I tried to override it.

[pkliczewski]

/lgtm

[dmartinol]

If you want to simplify the template and the documentation and, at the same time, provide more flexibility so that new sub-fields can be added if needed, you can just have a single structured JSON object representing the full configuration and then install it as:

spec:
{{ toYaml .Values.subscription.spec | indent 2 }}

Then you can provide a default in your values.yaml with a sample data. (in the above example should be under rhdhOperator.subscription.spec, of course you can name it as you prefer

[masayag]

I'm going to leave this one as is for now since the other operators follow the same method. We can re-work this in the future to have the same way to configure all of the components.

[dmartinol]

lgtm, will approve after a quick validation on my cluster

[dmartinol]

validated locally: apart from the notifications which are broken (as expected, IIUC), all looks good.

[openshift-ci]

New changes are detected. LGTM label has been removed.