Layered operator design

[gazarenkov]

The goal of this issue is redesigning the Operator making it layered for:

• separate the internal configuration logic (the biggest part) from the K8s API calls
• better testability, implementing the absolute most testing logic as plain unit tests, decreasing amount of big and slow K8s envtests
• better documentation and, therefore supportability, to be able to express how operator is designed.

[rm3l]

Priority right now is to have the first version of the operator out there for RHDH 1.1. We have something working even with all the imperfections in the codebase and tests structure, and QE/Docs will start trying it out as soon as possible.
Can we postpone this refactoring until after this first version is released?

[gazarenkov]

The thing is that our initial version is mostly POC (it is not good and not bad, we just had to start somehow), as a consequence:

• it is difficult to make Design/arch documentation since it mostly working as a plain script for creating K8s objects
• It is difficult to support and improve for the same reason
• it is difficult to test because logic is not layered, so all we can do is integration (envtest) tests for Controller, no unit tests which means:
  • slow run time
  • a lot of poorly structured code, which is difficult to understand (not being an author) and maintain

So, I would still highly recommend to look at #70 and not to postpone applying it unless there are no objections per se.
It is not that much work to do to check and fix if needed. It already contain more tests than older one and only a couple of integration tests are not passed (commented for the time) and mostly the reason of not passing is clear.
I believe spending some time now will save a lot of time in the future.

[gazarenkov]

JIRA