Evaluate Operator installation procedures

Summary

The Operator may be installed via:

• OpenShift OperatorHub (https://docs.openshift.com/container-platform/4.7/operators/understanding/olm-understanding-operatorhub.html)
• Repo (via scripts / make commands / kubectl apply <manifests url>)
• (Others methods?)
  • https://operatorhub.io/
  • https://artifacthub.io/

We should evaluate the available methods we provide for the GitLab Operator, as we currently only support installation via several make commands.

Details

The operator-sdk is largely responsible for the current layout of the project, but many projects I've seen have a deploy directory where the manifests are stored. This provides a straightforward method for installation that does not require having the project cloned locally. For example, JetStack's cert-manager manifest provides an all-in-one file that can be easily installed with kubectl apply.

Some references:

• https://github.com/nginxinc/nginx-ingress-operator/tree/master/deploy
• https://github.com/kubeflow/kfctl/tree/master/deploy
• https://github.com/jetstack/cert-manager/tree/master/deploy
• https://github.com/argoproj-labs/argocd-operator/tree/master/deploy
• https://argocd-operator.readthedocs.io/en/latest/
• https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator
• https://redhat-connect.gitbook.io/partner-guide-for-red-hat-openshift-and-container/

Acceptance criteria

• The installation methods available for the GitLab Operator support both OpenShift and non-OpenShift environments
• The installation methods available for the GitLab Operator match or are similar to installation methods for other operators (I say this so that users familiar with operators will find the process for the GitLab Operator familiar and straightforward)