I have chatted with Peter Braun about the current setup that exists for application-monitoring-service in order to understand what approach we should/could take, a summary is below including some suggestions for approaches we could take generally for MDS operators, ping Wei Li

Based on this discussion I believe we have two paths:

*1) *
Programatically check if the user is on OpenShift or Kubernetes
If on Kubernetes, create the Ingress object and possibly provide an alternative auth setup
If on OpenShift, create a Route object using unstructured type by passing a template which contains the required Route object.

This would result in one operator which supports both kubernetes and openshift - adding auth option to kubernetes may be optional depending on priorities

Problem/Concerns

• requires investigation into whether there is a way we can determine if the operator is running on openshift or kubernetes

*2) *
Wrap the existing kubernetes operator with a) an openshift specific operator or b) an ansible script (e.g. integreatly installer)

2a) create a separate operator which depends on the existing operator which adds the additional route and proxy config

Problem/Concern

• May not work on OpenShift 4 using OLM.

2b) wrap the operator in an Ansible script which creates the Route required and do the necessary config.
will this work? The updates required are to pass the extra container, add config to the deployment to point at a Service Account, annotate the Service Account with a redirect, and create the route object. Won't the operator re-update those resources if we change them manually using openshift?

Problems/concerns

• If we only provide the integreatly installer approach then the operator would not provide a path to install on OpenShift independently of RHMI

cc David Ffrench Camila Macedo Damien Murphy