[Discussion] Move git Controllers into devconsole-operator repo

[sbose78]

Proposal

Move Git-Service[1] controllers into dev-console-operator[2]. Effectively, merge the git-service repo into the dev-console-operator repo.

[1] https://github.com/redhat-developer/git-service [2] https://github.com/redhat-developer/devconsole-operator.

Context

When we started out building operators, we decided to not go for a monolithic architecture, and build small operators and be able to install them together using one of them.

However, it turns out that 'operator' dependency resolution happens for those operators 'released' to olm/marketplace only. Since, only one of our operators would be on olm/marketplace, any dependency management needs to be down on our own without any assistance from the framework.

We wanted to have an 'app service' and a 'git service' , which would be APIs services( good-old REST style or aggregated ) to enhance the user's import/export experience, and then it turned out that both are not easy in the current framework of things - which is why we are falling back to CRD/Controllers for everything in the git-service ( at least for now! )

Why

I was looking at 'installing' the Git-Service operator as part of devconsole-operator by adding it to https://github.com/redhat-developer/devconsole-operator/tree/master/manifests/devconsole/0.1.0/devconsole-operator.v0.1.0.clusterserviceversion.yaml

install:
    spec:
      deployments:
      - name: devconsole-operator
      ....
      ....
      - name: git-service
      ...
      ...

However, I hit a 'process' wall when..

1. I realized that

• one would have to manually keep the RBAC permissions in sync across both git-service and devconsole-operator repositories. ( you could automate a PR though...) . Every commit to git-service which has RBAC changes would need a commit to devconsole-operator with the cumulative list of rolebindings
• .. and possibly, tagged image with specific version ( because old images wouldn't need those rbac changes )

2. I looked up operators on https://github.com/operator-framework/community-operators and did not find any that uses multiple deployments in the manifest. Example: https://github.com/operator-framework/community-operators/blob/5fc3763d6a074e6aafbd6dd64cea07593994d764/community-operators/elasticsearch-operator/elasticsearch-operator.v4.1.0.clusterserviceversion.yaml

I don't wish to end up doing something which is different from the 'common' way of doing things as that could well lead us into unsupported territories.

In the near future, once we build a lot of capabilities into the Git Service controllers, we could publish it separately on the marketplace and consume it using the high-level dependency model. However, that is a lot of overhead to take care of, at this point.