OpenShift Console in the Operate First environment

[gagansk]

Make changes to the Operate First - Zero OCP (https://console-openshift-console.apps.zero.massopen.cloud/) to point the UI component to Curator-openshift-console rather than the in-built openshift-console.

DoD:

• OCP backend should be accessible via the curator-openshift-console.
• Curator tab should be accessible for the admins in the console.

┆Issue is synchronized with this Asana task by Unito

[tumido]

Hey @gagansk I've noticed this issue and the #31 PR as well.. This seems to go in a very different direction than operate first should head to in my eyes.

1. First of all, squashing years of development from another repository into a single commit completely erases history of the code and claims authorship of the code. This is not right.
2. How do you plan on maintaining this repository?

• Which branch did you build from? OCP 4.9, 4.8, 4.7, 4.6, master?
• How do you want to keep the console up to date with the cluster operator and keep track of it together with cluster upgrades?
• Do you plan on backport any OCP patch release?

3. Is there a reason why the curator is not contributing the tab/dashboard to the upstream?
4. Did you reach out to the OCP console team if there's any other way to get your tab into console image?

OperateFirst can't swap integral part of Openshift like OCP console for a custom image that is not kept in sync with cluster operator. We currently deploy 3 different OCP versions in 3 clusters (some on stable track, some on fast track - updated nearly bi-weekly), expecting more versions in the future... How do you want to ensure your console version matches those versions?

[gagansk]

@tumido I agree with you. #31 was for our development environment only. It shouldn't affect any Operate First operations.

1. Yes, squashing the entire OpenShift console repository to a folder isn't the right way. We wanted to test the UI with our backend for some tests and instead of creating another project and forking the upstream project, we squashed it to a folder. That is the sole purpose of Add console UI to repository #31.

2. We are planning to contribute to the upstream project. The plan is to fork the console upstream project and develop our code and make pull requests for the upstream. We are in talks with the OpenShift team about this. We are waiting to get their opinion on how we can contribute and on which branch we can base our code.

3. The 'console' folder in our repository is a placeholder for the forked console project and is for experimenting only. We haven't added any notes in the README.md of the Curator project, especially for this purpose.

@tumido @billburnseh Please let us know if the Operate First ops team accepts changes to the upstream projects such as the OpenShift console. If so, what are the requirements to accept the changes we might make for the OpenShift console?

[larsks]

@gagansk is it necessary to replace the console? Or can the curator console be run as a separate application?

[gagansk]

@larsks We were suggested by the OpenShift cost management team to integrate our UI with the console. I will talking to the OpenShift console team and the OpenShift cost management PM again to finalize this and will update this issue soon.

[gagansk]

Closing this issue since we no longer are pursuing the idea of OCP Console integration.