Refactor osbuilder operation to separate builds from artifact delivery

[jbalonso]

Currently, osbuilder does its work on an OSArtifact by creating a Deployment, such that the "real work" (building) is all done in init containers while the end workload is a server for the end artifact. There are also heavy assumptions that the artifacts should be delivered via node ports (one per artifact). This also seems to be an abuse of ephemeral storage (within pods) for long-term use (indefinite availability of the build artifact).

I propose:

• Putting the "real work" of the Deployment into a Job instead.
• Consolidate artifact-serving into a single Deployment, such that:
• • a PVC backs the artifact storage (the storage class should be configurable in the helm chart)
• • a single, configurable Service connects to it (allowing node ports, ingresses, load balancers... however the user desires)
• • the worker underlying this Deployment monitors the OSArtifact CRDs it is responsible for, garbage-collecting artifacts that are no longer backed by a CRD
• The final step of the Job is to PUT the artifact into the artifact server via a kube-rbac-proxy-guarded port

Notably, the configurability of the artifact server (the PVC and the Service) can be accomplished with basic helm chart machinery rather than eccentric configuration of the osbuilder controller.

[mudler]

Hi @jbalonso! Thanks for breaking it down, that sound a good plan to me.

Did you had a chance to have a look at our epic #116 ? I think most of your points are already crossing with it - there are no open issue for single items on the CRD as we need to still groom all the points, but we can start creating single issues and track them, this is already in our trajectory for Q4 so it sounds good to put in our agenda for the next office hours!