Get more out of Kubernetes' Operator Pattern

[mgoltzsche]

Currently most of the Jenkins X logic is implemented in the jx binary which is called everywhere. This results in the following problems:

• hardly possible to develop/test components in an isolated manner.
• not easy for the community to contribute.
• does not support easy replacement of certain components with others.
• does not offer as many extension points as k8s components usually have naturally when loosely coupled via the k8s API (CRDs/events) - currently k8s is mostly used as DB, very few controllers
• not all processes are modeled using a CRD: therefore some information can only be derived by joining multiple resources. Instead there should be a denormalized CRD for every business process to support simple k8s API queries and extension.
• not as resilient as it could be: implements long running business processes as a single piece of blocking code: On intermediate/temporary failure or pod termination eventually the whole process fails.
• cannot be called from a controller efficiently since long blocking code in a reconcile loop reduces concurrency (requires decomposition first).

Therefore I propose to establish best practices and an iterative approach to move logic from the jx CLI into k8s controllers following the Operator Pattern.

[salaboy]

@mgoltzsche my two cent.. this is easier said than done. The JX CLI tools is a Go binary as far as I am aware, and it encapsulates a lot of API calls to different Kubernetes components. It is not like the Operator/Controller pattern is not being leverage, it is more like most of the magix happens inside this binary and that is reused all over the place.. this avoid having services which expose APIs just to call other services (like the k8s apis or tekton) that are already there..

I will leave the experts to express their opinions here... but from an outsider point of view , the jx cli can be modularized.. but i believe that I would also keep the jx services to the minimum..

[salaboy]

@mgoltzsche can you give specific examples:

not all processes are modeled using a CRD: therefore some information can only be derived by joining multiple resources. Instead there should be a denormalized CRD for every business process to support simply k8s API queries and extension.

I am interested in that one ..

[mgoltzsche]

@salaboy examples:

• while Jenkins X supports promotions there is no particular CRD that reflects it. Instead this information needs to be derived from PRs and builds which is cumbersome. Having a CRD would certainly help.
• Apparently not all information is synced from Tekton PipelineRun CRs to jx' corresponding PipelineActivity which is why both have to be joined in some cases - this is probably the most trivial to solve, especially since there's already a build controller which copies status information from tekton to jx CR. Generally I'd like to establish the idea that CRDs should be denormalized to be easily queryable which is important a) for users to get a better understanding of jx and b) for the community to simplify contribution (e.g. apps) because all data is easily accessible in a k8s standard way.