MEP: Standard Linux Distribution ("distro")

[afbjorklund]

See #9992

[medyagh]

if you think this the right way to do, we could approve this and work on it for Q1 2021.
should we have a transition period where people who really love our Buildroot ISO keep using it ?

[afbjorklund]

should we have a transition period where people who really love our Buildroot ISO keep using it ?

Indeed, the plan was to have multiple ISO files (one being the default) - and use URL to select the other

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: afbjorklund, priyawadhwa, tstromberg

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [afbjorklund,priyawadhwa,tstromberg]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[medyagh]

one i think I liket his MEP to conver is the upgrade plan,

it seems to me the previous versions of minikube will not be able to upgrade to newer verison of minikube if we change the ISO's OS.
and they would need to do selete and start a new one.

if that this the case, we need to discuss it and possibliy roll out minikube 2 which will not support upgrading old versions.

this would mean minikube would have to add a mechanisim to detect old iso and and warn user to delete and start again.

[afbjorklund]

We have changed iso before, when we went from boot2docker to buildroot...
As long as the files on the /var disk image are compatible, it should be doable.

It's also not a blocker, even if it should require users to delete their cluster ?
I think we need a prototype, before we can tell if an upgrade is posssible or not

[tstromberg]

Agreed. In the past it hasn't been necessary to ask users to delete their old VM's. Given how few entry points minikube actually has into the built-in userland, I don't foresee compatibility issues. I can see upgrades potentially being something to work out, but outside of the scope of this MEP. minikube already handles Ubuntu (docker) and buildroot (ISO) with minimal behavioral differences.

…

On Fri, Jan 15, 2021, 7:52 AM Anders Björklund ***@***.***> wrote: We have changed iso before, when we went from boot2docker to buildroot... As long as the files on the /var disk image are compatible, it should be doable. It's also not a blocker, even if it *should* require users to delete their cluster ? I think we need a prototype, before we can tell if an upgrade is posssible or not — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10067 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYYMF7NLHP4D5L3BIBKI3S2BQEVANCNFSM4VOLQMXQ> .

[afbjorklund]

Before we look into making it a "general" distribution, we need something for the upgrade path.
Not saying that this is the only way, but it was one of the options (keep the distro, but external)

I was going to look into A/B booting, like this: https://source.android.com/devices/tech/ota/ab
Basically you have two installations, one active and one passive (where you do the upgrade)

Alternative to using a package manager.

---

This would be similar to minikube rebooting with a new ISO, but slightly more hard disk-centric.
Both require that you also have a third image, where you store the data that you want to keep.

I also had a fourth* image, that was used for pulling the images from (like the preload tarball)
This allows upgrading the container storage, if needed. But mostly used for the first installation.

And a fifth image for /data, but anyway.

[afbjorklund]

Agreed. In the past it hasn't been necessary to ask users to delete their
old VM's. Given how few entry points minikube actually has into the
built-in userland, I don't foresee compatibility issues.

I also wanted to make some drastic changes to the userland, like excluding the runtimes.

#9989