Closed masayag closed 8 months ago
@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 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.
@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 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?
@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 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.
@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 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.
@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.
@jianrongzhang89 may I ask for your assistance with this PR? Something with the current version of the PR misbehave for me: The chart creates the Backstage CR but is not being reconciled by the controller. Using quay.io/janus-idp/operator:0.1.0 (got the same result with next). The readme.md is updated in the this PR.
@jianrongzhang89 may I ask for your assistance with this PR? Something with the current version of the PR misbehave for me: The chart creates the Backstage CR but is not being reconciled by the controller. Using quay.io/janus-idp/operator:0.1.0 (got the same result with next). The readme.md is updated in the this PR.
I think I see the problem:
Image quay.io/janus-idp/operator-catalog:0.1.0
has a different CRD version than quay.io/janus-idp/operator-catalog:dev
rhdh.redhat.com/v1alpha1
vs backstages.janus-idp.io
→ oc get crd | grep backstage
backstages.janus-idp.io 2024-02-18T19:15:29Z
backstages.rhdh.redhat.com 2024-02-18T14:00:04Z
While the CR created by the chart is of backstages.janus-idp.io
API.
@jianrongzhang89 may I ask for your assistance with this PR? Something with the current version of the PR misbehave for me: The chart creates the Backstage CR but is not being reconciled by the controller. Using quay.io/janus-idp/operator:0.1.0 (got the same result with next). The readme.md is updated in the this PR.
I think I see the problem: Image
quay.io/janus-idp/operator-catalog:0.1.0
has a different CRD version thanquay.io/janus-idp/operator-catalog:dev
rhdh.redhat.com/v1alpha1
vsbackstages.janus-idp.io
→ oc get crd | grep backstage backstages.janus-idp.io 2024-02-18T19:15:29Z backstages.rhdh.redhat.com 2024-02-18T14:00:04Z
While the CR created by the chart is of
backstages.janus-idp.io
API.
Yes with the PR for the RHDH operator https://github.com/janus-idp/operator/pull/201, the API group has changed to backstages.rhdh.redhat.com.
I suggest you create a fresh cluster to run your test. If you can not get a new fresh cluster, make sure you remove backstages.janus-idp.io CRD from the cluster first.
New changes are detected. LGTM label has been removed.
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.