Discussion on switching to use universal developer image in devfile samples

[yangcao77]

Which area/kind this issue is related to?

/area registry

Issue Description

Che team is planning to move to a universal image for their scenarios. Should devfile samples/stacks in our registry be updated to use the developer image?

Can we update tools container of those devfiles to use the developer image like quay.io/devfile/universal-developer-image:ubi8-d433ed6 instead of the quay.io/eclipse/che-java11-maven:nightly images that no longer exists ?

Originally posted by @benoitf in devfile-samples/devfile-sample-java-springboot-basic#1 (comment)

[kadel]

I just want to make sure that everyone understand the trade-offs of using universal developer images.

I understand that this will help Che with startup time. But on the other hand it will increase startup time for anyone using odo with CRC or minikube. Those users will have to download 1.5Gb image into their CRC/Minikube. For a lot of people downloading 1.5Gb might be a problem.
@slemeur, what do you think about this? I'm worried about impacting this CRC/Minikube users.

[yangcao77]

Here's the size and download time of the images, the developer image took a significant amount of time for the first time download.

	Image size	first time download time
developer image	1.4G	1m18s
java-quarkus	808MB	59s
java-springboot	334MB	23s
python	68MB	6s

If we want to update all samples to use developer image, it does have pros and cons:
cons:

• first time build takes longer, can notice huge time difference for smaller images(python/node)
• will be a problem for Minikube/CRC users with big image size

pros:

• convenient to developers: contains a lot tools, easier to exec into image and debug
• with the universal image, no need to download different images for different samples. after the first time download of the developer image, and following build time of all samples will be shorter.

[l0rd]

I understand that this will help Che with startup time. But on the other hand it will increase startup time for anyone using odo with CRC or minikube.

Please do not make it a Che vs odo thing. Che is used on CRC and minikube too, reducing the size of our images has always been important (just come at Che community call and ask if alpine is better than ubi and you will see :-)). That said today priorities have shifted from local and on-prem to managed services. For those scenarios a universal developer image makes more sense (for both odo and Che).

[kadel]

For those scenarios a universal developer image makes more sense (for both odo and Che).

I'm afraid that this is not entirely true

As I understand, Che has mechanism that will make sure that that image is cached on all nodes on the cluster, so every time the devworkspace is started it is quick. I can see how managing just one big VM like image makes sense here.

Odo doesn't have anything like this and will never have. This means that from odo's point of view this will just slow down startup significantly. And not just the first one, every time the Pod is scheduled on a new node it will have to wait for 1.4Gb to be downloaded again :-/

I want to make sure that everyone is aware that this has also its downsides (and in my option they are not small one)

[l0rd]

@kadel you are completely right for customer managed clusters. I am talking about cluster managed by Red Hat, clusters that are setup and optimized by us to run developers tools (with Che, odo etc...).

The main difference is that we are optimizing Che to be a managed service rather than a service managed by a customer but odo doesn't have the same requirement. That's completely fair.

[Jdubrick]

Closing issue. It looks like our samples are using UBI currently and no additions to the discussion here have been made in some time.