Update Ubuntu from focal (20.04) to jammy (22.04)

[armanbilge]

Attempting to revive #814 by @tnir.

[gitpod-io]

[gitpod-staging]

[david-bakin]

👎 👎 Is an upgrade of Ubuntu between major versions really so trivial it can be done with a PR and no testing in deployment by customers? I don't know, which is why I'm asking. It's not simply the Linux kernel - it's also all the mainstream repositories holding binaries and development headers and libraries. What happened the last time Gitpod upgraded Ubuntu versions? (Or has it ever?)

Couldn't it mean, for example, that lots of customers will now have .gitpod.yml start tasks and custom Dockerfiles that won't build because the upstream apt repos are different? Shouldn't there at a minimum be a "legacy" workspace-base maintained, with perhaps a different name such as workspace-base-20.04, so that customers can at least try to recover their old build environment? Perhaps the entire stack of different workspace images (or at a minimum, a workspace-full-20.04 be built and kept until the impact is known? Maybe all it takes is to tag the last known good 20.04 images of each variety? I ask again: shouldn't there be testing, in deployment, by actual users???

Perhaps a better approach would be to build the entire stack of images -base, -cpp, -python, -full etc. with different names (e.g., workspace-full-22.04) and encourage customers to try them out with their own workspaces, see what happens?

(Is there a design document - that I'm not privy too - that goes into the risks/benefits? Has anyone checked to see what competitor cloud development services do to upgrade the base system - or discovered that they know there are no problems?)

Seems like there's potential for making the customer experience very destabilizing! The base PR #814 has no discussion of this itself but defers to #810 which only discusses it from Gitpod's internal point-of-view, not anything the customer might experience. Yet note that even #814 has this comment pointing to at least one problem in someone else's dockerfile when upgrading to 22.04 so who knows what will happen to actual customers with their workspaces???

Thanks. I did not intend to merge this within days since I already know the problem at least on Gitpod cloud (gitpod.io).

cf. tianon/docker-brew-ubuntu-core#236

(Gitpod stability being already a concern of customers means this upgrade should _not be taken lightly. And I believe that this upgrade is a customer-facing decision that has the potential to destabilize things, and none of the predecessor PRs have a discussion of the tradeoffs from the customer POV nor do they point to an internal document (which I have no access to) that would discuss it for Gitpodders. It's a tough engineering (and product planning) problem for Gitpod, not something that can just be pushed to production someday to see how it shakes out.)

[armanbilge]

Is an upgrade of Ubuntu between major versions really so trivial it can be done with a PR and no testing in deployment by customers?

I agree, it's not trivial.

It's a shame that GitPod didn't make an image available earlier so users could begin trying it. For example GitHub actions made 22.04 available for beta testing originally in April before making it Generally Available in August. It will replace their default CI runner in the near future, at which point 20.04 will have to be opt-in.

But Ubuntu 22.04 is here, it's LTS, and soon it will be default in GitHub CI. That means (at least for me) it will be a problem if I cannot easily use it when I open any repository on GitHub with GitPod (i.e., not requiring custom configuration).

[ianhellstrom]

I’d be happy to try it out, if I had the opportunity, even if for the time being it would be the base Gitpod image, created manually and not yet automatically as that will probably require modifications to the way the images are built.

Perhaps a better approach would be to build the entire stack of images -base, -cpp, -python, -full etc. with different names (e.g., workspace-full-22.04) and encourage customers to try them out with their own workspaces, see what happens?

It would also allow users to peg their workspaces, which is great at preventing unwanted changes from happening and ruining the experience.

[kylos101]

Closing in favor of #1017