Moves ./controllers into ./internal and ./main.go into ./cmd

[m1kola]

Description

• Moves ./controllers into ./internal
  Unless we have intention to export ./controllers as a library - it makes sense to move this package into ./internal. If we want to expose ./controllers at some point - I would suggest moving it into ./pkg.
• Moves ./main.go into ./cmd
  We want to add more commands into the repo (Dependency Library + CLI #206, for example) so would be great to avoid having one of the entry points in the repo root

Note: go-apidiff will complain since we no longer export stuff from ./controllers.

Reviewer Checklist

• API Go Documentation
• Tests: Unit Tests (and E2E Tests, if appropriate)
• Comprehensive Commit Messages
• Links to related GitHub Issue(s)

[tmshort]

I question moving main.go. As #206 could be done in the deppy repo (or even the kubectl-operator repo), and not necessarily in this repo.
I agree we probably don't need to export most (if any) of operator-controller now, but maybe in the future?

[everettraven]

The actual move looks fine to me, but I agree with @tmshort that we may not need to export anything now, but we could in the future. I think this gets into the discussion of the different supported use cases and form factors that OLMv1 could come in and is probably a discussion much to large for this PR.

That being said, if we find in the future that some stuff needs to be exported we could always refactor it again

[m1kola]

I question moving main.go. As #206 could be done in the deppy repo (or even the kubectl-operator repo), and not necessarily in this repo.

@tmshort I would still suggest to move it to cmd as it is very command to place entry points in cmd in Go projects.

agree we probably don't need to export most (if any) of operator-controller now, but maybe in the future?

That being said, if we find in the future that some stuff needs to be exported we could always refactor it again

@tmshort @everettraven I think it is easier to export something than remove publicly available API. I'm in favour of starting with as few exported things as possible and export as the need arises.

[everettraven]

I'm in favour of starting with as few exported things as possible and export as the need arises.

@m1kola I think that is reasonable

[tmshort]

I'm in favour of starting with as few exported things as possible and export as the need arises.

@m1kola I think that is reasonable

According to Spock, "I was not attempting to evaluate its moral implications, Doctor. As a matter of cosmic history, it has always been easier to destroy than to create." but not in the case of APIs.

So, yeah.