-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ImagePullPolicy should be configurable for every container #14698
Comments
@l0rd |
Since it is related to installation mechanism I mark this issue as |
Let me provide information about the status of this on the Operator side:
This one is a bit special, since its overriding depends on the method of the Che operator installation:
Already available as fields in the custom resource.
This is already possible by setting the appropriate Che server environment variable:
|
Thanks @davidfestal I have updated the description |
It is mentioned that:
I would like to set image pull policy for cheEditor plugin (theia ide) and another chePlugin type of plugin. Please show sample code/configuration. |
@svkr2k I did not found where it's declared in CR model, but you should be able to configure these properties via customCheProperties. So, edit your Che Cluster CR spec:
server:
customCheProperties:
CHE_WORKSPACE_SIDECAR_IMAGE__PULL__POLICY: IfNotPresent
CHE_WORKSPACE_PLUGIN__BROKER_PULL__POLICY: IfNotPresent
|
I think the images below are the main ones slowing WS startup for us now, they are set to pull always and there is no option to configure:
If these were able to be set to IfNotPresent by default, I think our workspaces would start in under 10 seconds :) |
@davidwindell Sorry to pop in after a month, I agree that we should be able to set PullPolicy for every container, but wanted to share some background on how this affects workspace startup times. The messages you are seeing do not necessarily mean that the entire image is being pulled every time, and it's due to some confusing semantics around pull policies. A pull policy of This means that I did a fairly deep-dive into this last year, but I can't find the issue where I shared some graphs on how pulling affects workspace start time. The long and short of is is that if images are already cached on the node where the workspace is running, we save at most 3-5 seconds per workspace start by setting We have a utility you might be interested in taking a look at, that we originally wrote to support pre-pulling workspace images on che.openshift.io: https://github.com/che-incubator/kubernetes-image-puller. It basically creates a daemonset on the cluster that keeps the main large images in a workspace running so that they are always present on every node. |
Heh, I should read ALL the previous comments before I post something :) My point was made others already :) |
@l0rd I've just discussed this topic again with @tolusha . |
@skabashnyuk don't forget the jwt-proxy in that list :) |
Default confiruation
Configuration with:
I see two interesting parts.
|
Is there any way to fix for mkdir and stack containers? |
I'm thinking about that |
@tolusha so now you've closed this, can you confirm the ImagePullPolicy can be specified for the jwt proxy, etc? che-plugin-metadata-broker |
@davidwindell spec:
server:
customCheProperties:
CHE_WORKSPACE_PLUGIN__BROKER_PULL__POLICY:
CHE_WORKSPACE_SIDECAR_IMAGE__PULL__POLICY:
CHE_INFRA_KUBERNETES_PVC_JOBS_IMAGE_PULL__POLICY: |
Awesome, thanks @tolusha - this works and workspace startup time is so much faster with IfNotPresent now, ~10 seconds |
Is your enhancement related to a problem? Please describe.
When deploying Che some images pull policies can be set easily (i.e. for
che-server
) but others are not and it'simagePullPolicy: Always
no matter what.That makes it impossible to start Che or even a workspace when offline. Even if all the images are all available on the local disk.
Describe the solution you'd like
JWT proxy image pull policy should be configurable (in che.properties, helm chart and operator)
With the Helm chart it should be possible (but it's currently not) to:
With the Operator it should be possible (but it's currently not) to:
custom
operator config map with a map inside the custom resource. #14635)The text was updated successfully, but these errors were encountered: