Get more out of Kubernetes' Operator Pattern about enhancements HOT 3 CLOSED

@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..

from enhancements.

@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 ..

from enhancements.

@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.

from enhancements.