Move DevConsole Proxy to be OSP-managed

Goals

The DevConsole proxy, which is used to proxy Openshift Pipelines services like Results, Artifacthub, etc, is currently is part of the main Openshift Console codebase. The proxy functionality is required for the Console Plugin and (if the Console Plugin is disabled) the main Console's Pipelines page. Even though it's Pipelines specific code, since it lives in the main Console repository it is on a different release cycle than Pipelines and is not maintained by the Pipelines team. This makes it difficult to provide maintenance estimates for customers and coordinate changes with other Pipelines components.

The proxy functionality should be moved into the Openshift Pipelines org, ideally into the Console Plugin repository.

Requirements

Out of scope

• Removing the Console Proxy from the Openshift Console codebase
• Switching the Openshift Console (not the plugin) to use the new proxy

Dependencies

The Console Plugin will need to be modified to use the new Proxy's endpoint, this will likely need to be handled by one of the ODC team members while our team has no UI developers familiar with React.

Background, and strategic fit

• The proxy will need to be publicly exposed to reverse-proxy from the UI (users' browsers) to the private endpoints of the various Pipelines services
• The Proxy should not forward to every Pipelines service, only those which we enable- currently Tekton Results, Artifact Hub, and oddly (in the case of creating a Webhook) Git providers like Github and Gitlab
• The proxy is currently written in Go. We can move the go code into a dedicated package, but there is no strict go dependency. If possible a no-code option such as an nginx config or even a proxy config on the ConsolePlugin CR would be preferable.

Assumptions

• The Console Proxy's functionality has no dependencies on running inside the Console itself

Customer Considerations

• This change should be completely transparent to the customer; how the request is proxied from the UI to the component is an implementation detail
• If the new Proxy fails for some reason, for the sake of UX we should fall back to the Console Proxy and make sure the errors are effectively logged for debugging. Users need not be aware which proxy is forwardingthe request.

Documentation Considerations

Release notes will be necessary, but no additional documentation should be required since the change should be transparent to the customer.

What does success look like?

< Does this feature have doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>

QE Contact

< Are there assumptions being made regarding prerequisites and dependencies?>

< Are there assumptions about hardware, software or people resources?>

Impact

< If the feature is ordered with other work, state the impact of this feature on the other work>

Related Architecture/Technical Documents

• Current proxy implementation: https://github.com/openshift/console/tree/main/pkg/devconsole
• Console Plugin repository: https://github.com/openshift-pipelines/console-plugin/tree/main
• Nginx reverse proxy documentation: https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
• Console Plugin CR proxy config documentation: https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/console_apis/consoleplugin-console-openshift-io-v1#spec-proxy

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment