As an Admin, during the Eclipse Che installation flow, I want to have a possibility to optionally install the kubernetes-image-puller for faster workspace startup

[ibuziuk]

Is your task related to a problem? Please describe.

Currently, kubernetes-image-puller is the operator which is installed and managed separately from the Eclipse Che operator - https://www.eclipse.org/che/docs/che-7/administration-guide/caching-images-for-faster-workspace-start/

Need to explore the possibility of making kubernetes-image-puller as an optional dependency of the Eclipse Che operator.

Describe the solution you'd like

The installation flow could be the following:

• Admin installs Eclipse Che operator via OperatorHub
• During the CheCluster CR creation there should be an option to enable k8s-image-puller (via both yaml an UI) similar to how the OpenShift oAuth / TLS mode are currently managed.

• If kubetenets-image-puller option is enabled Eclipse Che operator should create the KubernetesImagePuller with the set of images for pre-pulling that is relevant for the current version of Eclipse Che e.g. for version 7.20.0 :

apiVersion: che.eclipse.org/v1alpha1
kind: KubernetesImagePuller
metadata:
  name: image-puller
spec:
  daemonsetName: k8s-image-puller
  images: >-
    java11-maven=quay.io/eclipse/che-java11-maven:7.20.0;che-theia=quay.io/eclipse/che-theia:7.20.0

Describe alternatives you've considered

Manage Eclipse Che and Image Puller operators separately as it currently works today - https://www.eclipse.org/che/docs/che-7/administration-guide/caching-images-for-faster-workspace-start/

Additional context

N/A

[tomgeorge]

Is this going to install the image puller operator? Or can we assume it is installed already?

We could also do this via helm without the KubernetesImagePuller CR.

[ibuziuk]

@tomgeorge we should not expect that operator for image puller is installed.

We could also do this via helm without the KubernetesImagePuller CR.

That's an interesting idea. I'm not sure how difficult will it be to make the image puller operator an optional dependency of the che operator, so potential solution indeed could be using image-puller Helm charts / OpenShift templates in the Eclipse Che / CRW operators @l0rd wdyt?

[tomgeorge]

If we install the kubernetes image puller operator, we can either install it in it's own namespace, or install it in eclipse-che.

In it's own namespace

• requires more permissions for che-operator
• predictable location, guards against multiple KubernetesImagePuller CRs and operator pods
• potentially makes the kubernetes image puller operator less flexible

In eclipse-che

• should be able to create KubernetesImagePuller CRs in it's own namespace
• possible to have multiple image puller operator pods and CRs in different namespaces
• increased "locality" of information pertaining to the Che installation in total

The other option is Helm which I haven't tried yet. I think the che-operator could make a CronJob with the chart in the file system that runs helm install ...

[ibuziuk]

I personally would opt for the own namespace for the image puller operator to make the installation more predictable.

[nickboldt]

As per video walkthru https://drive.google.com/file/d/1eu28GAgGzTjY31JGhspCHaxeKiYzXKp9/view it seems like this solution requires the k8s image puller operator, not just the k8s image puller image.

Is this a hard requirement? Adding a second operator + metadata images to the BOM for CRW 2.6 would be a fair amount of work and would make CRW involve releasing two operators in every release, doubling the amount of operator-based testing we have to aleady do.

[tomgeorge]

Is this a hard requirement?

From a UX experience, no, as the user could just not enable the image puller. But that is not a super great answer.

We decided to use the image puller operator and OLM because it seemed like something that you could expect many users to have available to them (OLM), and those APIs will install everything (Deployments, Service accounts, RBAC, etc.) for you automatically as part of the Subscription and InstallPlan it creates for a ClusterServiceVersion.

This isn't the only way to install this, though. We had talked about having the che operator creating a Job that runs helm install on the kubernetes image puller helm chart. We could also have the che operator deploy the image puller in some hard-coded way.

@l0rd @davidfestal Do you have any opinions on this?

would make CRW involve releasing two operators in every release, doubling the amount of operator-based testing we have to aleady do.

Do you definitely need to downstream the image puller operator? The che operator and image puller operator are released independently today, if the were downstreamed, would they need to be released in lockstep?

[ibuziuk]

Do you definitely need to downstream the image puller operator?

Same question here, both image-puller and image-puller-operator are UBI based https://issues.redhat.com/browse/CRW-875 (what is more, upstream image-puller operator is already reffered in the CRW docs https://access.redhat.com/documentation/en-us/red_hat_codeready_workspaces/2.5/html/administration_guide/caching-images-for-faster-workspace-start_crw as the recommnded way of caching images for faster workspace start)

@nickboldt So, I do not understand what is expected to be downstreamed at this point (the whole excercise with the UBI switch meant to be done to remove the need of doing any downstreaming)

[ibuziuk]

PR is merged. Closing