Changing default console to Debian and include most common tools to it

[olljanat]

Based on #6 Ubuntu looks to be most common console so I propose that we change it to default and drop other consoles (to simplify maintenance).

Then we can also implement these changes to defaults:

• Install open-iscsi with apt (and drop open-iscsi system service) like proposed on Improve os iscsi service rancher/os#2636
• Install these commonly used tools by default:
  • iputils-ping
  • git

Those will increase size of image a little bit but we can also create releases for virtualization platforms without firmwares (using rancher#2810) so outcome is most probably very near of current one.

@ToeiRei I see that you are using Debian console, any objections about using Ubuntu instead of it?
@PrplHaz4 I see that you are using default (Alpine) console, any objections about using Ubuntu instead of it?

[PrplHaz4]

@PrplHaz4 I see that you are using default (Alpine) console, any objections about using Ubuntu instead of it?

I've mostly stuck with default due to a lack of understanding the implications of switching. A more functional console would definitely be useful as long as it doesn't impact the immutability/persistence model of the system as a whole.

Not being able to do a simple apt-get in a lot of cases has forced me to think about how to push all reproducibility(?) into config files (near gitops?) and persistent volumes which simplifies backup/restore immensely IMO.

[ToeiRei]

I tend to keep the console slim and dislike Ubuntu for some very obvious reasons.

[olljanat]

I tend to keep the console slim

I too which why 58 MB Ubuntu console is better than 76 MB Debian console 😎

and dislike Ubuntu for some very obvious reasons.

@ToeiRei can you share those reasons for us who it is not that obvious? I switched from Debian to Ubuntu about 15 years ago because Debian development was too slow and it was missing too many application/modern versions of them.

[ToeiRei]

Ubuntu and I had quite a past. First off it's debian based. Its roots are far more stable than ubuntu itself.
Back some time they had horrible driver updates (UMTS stick driver was lost during some minor kernel update - do that to an enduser with no clue...) Another shady thing was their attempt with the display server 'mir' plus some privacy breaches like integrating amazon search in the start menu and that list goes on - I could fill pages with things that just suck from what cannonical did. That's why I do not and won't use it.

Besides that, debian is for my feel a bit more grown up and updates don't break that much. Why changing the default console anyways? Aren't we continuing rancherOS in some way keeping their simplicity? We're still speaking of a server, not a desktop machine.

@open-iscsi - I do not need it and I'm glad if I can disable it.

[olljanat]

Why changing the default console anyways?

For two reasons, first of because I don't want maintain anything which is not really needed. Other reason is new Docker Hub rate limits which you hit very easily if you deploy bigger set of servers which each will then download another console. Default console is included to ISO file so there is no need download it after server deployment.

Aren't we continuing rancherOS in some way keeping their simplicity? We're still speaking of a server, not a desktop machine.

Yes that is plan but I still want questioned that are five alternative consoles really needed and are using correct one as default?

open-iscsi - I do not need it and I'm glad if I can disable it.

Yea, I will use my veto right and include it to console (it looks to be quite small tool anyway) but most probably it can be still disabled by default.

Anyways, It looks that we cannot reach consensus about Ubuntu console.

Then next question to @the-bort-the @tomaswarynyca that what you are think about using Debian console instead of Ubuntu?

[ToeiRei]

Small addition about ubuntu which is even more relevant: they change up stuff quite drastically with every LTS version they use. Netplan as an example vs /etc/network/interfaces as that's the most recent one that I recall from the top of my head. Not sure if we want to have a clusterfuck situation on major updates on the ubuntu side.

For deployments even I do have a partial mirror of my containers here, so rate limits are no real issue - as even most kubernetes clusters have per default. So that's not an issue I see - and homelabs usually do not have large scale deployments. If that's still a big concern of yours, wouldn't it be better to add support for dockerhub alternatives like quay.io?

[olljanat]

Btw. I noticed that there is actually six console options on Rancher OS (not five like I said earlier) because default is not based on alpine like I expected but it is actually totally custom console.

Anyway, I created now also first beta release under BurmillaOS name which uses now Debian as default (and only console option for default), it is also bundled to ISO file (which increased its size 25 MB) and contains also other stuff which with I have been working on. You can find ISO file and more detailed release notes from https://github.com/burmilla/os/releases/tag/v1.9.0-beta2 Version number is 1.9.0 because it is still using 4.14.x series kernel and it is trying to be compatible with Rancher OS 1.5.x (need still figure out how to upgrade from it).

[tomaswarynyca]

In my opinion it is necessary to choose the most stable and easy to scale console for a future, the one that more adapts to that is the one of Debian that follow a solid standard. Since we are consulting you @olljanat is already considered safe to upgrade to v1.9.x in production?

What @ToeiRei says is to take into account, we must see that another service can be used to not have to pay dockerhub premium because the limitation will be a problem in the short term.

@olljanat Thank you very much for all the work you are doing to avoid dropping the RancherOS project.

[ToeiRei]

@tomaswarynyca I run the 1.9 version and had no issues in my homelab. Nothing strange in here - kernel is the same and the rest of the stuff seems stable so far.

[olljanat]

@tomaswarynyca kernel and docker versions are stable for sure but on renaming from rancher to burmilla I needed modify huge amount of files and I'm not yet sure if that have caused new issues or not.

So I recommend that you use some time to testing it on development/preproduction environments first. Also I can see that you use docker-machine which I have not tested.

PS. Looks that we have decission about use Debian as only console at least on 1.9.0 version so I will close this one now.

[olljanat]

@tomaswarynyca definitely not production ready. I started to list known issues to #13