che-bot
commented
3 years ago Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.
Mark the issue as fresh with /remove-lifecycle stale in a new comment.
If this issue is safe to close now please do so.
Moderators: Add lifecycle/frozen label to avoid stale mode.
Haskell, Scala, Bazel and probably other stacks create big caches of artifacts and files in non /projects folders like ~/.cache or /tmp. In most cases some of those files can be reused from the docker image, then project-specific content can be added too upon consequent builds (including ci/cd builds like tekton-pipelines with storageclasses).
osio: the changes to those pre-filled cache folders in the docker image won't persist upon workspace restarts, with the downside of loosing them if a volume is set to persist the changes in the meta.yaml for the plugin containing the sidecar (same applies to CLI containers in devfile). This causes an empty content of the freshly created volumes and everything (what came with the docker image and the new project-specific artifacts) to be downloaded and built, in some cases causing resource exhaustion in che.osio free tier with small example projects.
local: to locally deployed instances of che, even though caches can be set to persisted (minikube requires storage class workaround), the issue of cli/sidecar volumes empty folders applies too and extensions or build/run tasks redownload stuff that was populated in docker image just like in che.osio, resulting in repeated content: once in container images overlayfs layers and once in volumeclaim mounts (hostpath/nfs/etc) for every workspace that uses the affected sidecar. so the impact in bandwidth and storage can be more noticeable depending on use case location, ISP and workspaces number.
the result is resource exhaustion in che.osio or falling to rebuild project artifacts on every workspace restart (costs time).
Feature Request: adding the "overlay" property to sidecar/cli volumes created from meta.yaml/devfile.yaml when available.
maybe this feature can apply for organization-wide use cases too. so that all workspaces running in the same node, sharing an extension, will run the download/copy/create task only once and some times not even once when docker image has the stuff.
reference: https://serverfault.com/questions/841238/how-to-use-overlayfs-with-docker-volumes
rough comparison table