imagePullPolicy of Always leads to unnecessary pulls against Docker Hub rate limit, spec should specify pull policy and possibly provide other options

[scottkurz]

Is your feature request related to a problem? Please describe.
I might want to specify a pull policy Always vs IfNotPresent in my devFile. Perhaps a default should be specified as well.

Describe the solution you'd like
A specified default pull policy plus the ability to choose a non-default explicitly.

Additional context
Depending on the response it might also require an issue on 'odo'.

[l0rd]

@scottkurz that may be worth considering. That's for a component of type containerImage only or for other component type as well?

[scottkurz]

@l0rd - I need to educate myself before I can respond. I am using odo v1.2.2 experimental mode but am working with a type: dockerimage component.. which I see now has been deprecated. Short answer: "I'm not sure yet". Thanks.

[scottkurz]

Picking this up again, I think the devfile library is setting imagePullPolicy to Always here:
https://github.com/devfile/library/blob/1ef3a20a2f428a7071e25367d67df7b58f07718b/pkg/devfile/generator/utils.go#L146

With the introduction of Docker Hub rate limiting, our Always policy is going to result in already-pulled images getting unnecessarily counted against your rate limit.

Using the terms here it seems a waste of pulls to use Always with a "unique" tag.

On the other hand, for a "stable" tag, the devfile author might want to suggest Always, knowing that the image behind the tag may change, but the user may want to select IfNotPresent semantics, possibly to pin down the contents, and/or
possibly to avoid count against rate limits.

That said, there's something to be said for keeping things simple, so if in users' real world this isn't a problem then I could see keeping things as they are now.

[amisevsk]

To summarize a recent discussion in a call (feel free to correct if I have details wrong):

It would be useful to be able to override the imagePullPolicy applied to pods because:

• Users could encounter rate limiting issues as described above
• We're doing something different from the Kubernetes default (where "latest" images get an Always pull policy and other images get IfNotPresent)
• Setting IfNotPresent can be useful in specific cases where startup time is critical (even though Always doesn't download all layers, checking the image can take significant time)
  • For example, the DevWorkspaceOperator and Eclipse Che have global configuration properties for defining the default imagePullPolicy that gets applied to all containers for this reason

On the topic of defaulting to the Kubernetes behavior (Always for "latest"), one hard-to-notice issue users may run into is that it would mean the actual image run for e.g. a "nightly" tag depends on cluster state -- you could get a stale image if the node the pod is assigned to already has an old version cached.

We also discussed how such a setting could be defined:

• Through attributes, either as a specific setting within attributes or as part of a podSpec or container patch that gets applied to the k8s object
• As a field within component.container

Final caveats to consider:

• We should take care in which elements of the podSpec are included in the devfile API; we could end up with a copy-paste reworded podSpec in the API which doesn't make life easier for anyone.
• Documenting such features could be difficult, if the goal is user-friendliness, as the impact of image pull policy can be complex.

[scottkurz]

To summarize a recent discussion in a call (feel free to correct if I have details wrong):

@amisevsk - I think you represented the key points raised. If there's a next step I can help move this along with, please let me know. Thanks

[michael-valdron]

/area library

[michael-valdron]

The imagePullPolicy can now be set with container-overrides: redhat-developer/odo#4494 (comment)

With this being the case, I feel that this issue can be closed now.