Console container not updated after upgrade about os HOT 15 CLOSED

WDYT, should we change console to non-persistent by default in 2.0.0 release version (or RC2 if we release that)?

After all it is very simple one line change to this

As recap for those who have not followed whole story. In RancherOS, default console was non-persistent but others was persistent and because in #9 we decided to switch to Debian console it did came as persistent.

Let vote. Leave give 👍 if you support changing console to non-persistent and 👎 if you prefer to keep it console persistent by default.

from os.

Is this the intended behavior that I have to manually update the console container with:

Yes, that why it is also mentioned in documentation https://burmillaos.org/docs/installation/upgrading/#upgrade-rancheros-to-burmillaos

That is because some users like to store some files to console which will disappear on console upgrade.

from os.

But this is only mentioned under "Upgrade RancherOS to BurmillaOS". Maybe there should be a mention also under https://burmillaos.org/docs/installation/upgrading/#upgrading-1, that if you want to use the latest console container you must run sudo ros console switch default.

Agreed - it was not immediately clear to me that every upgrade would need sudo ros console switch default to get the latest. As a user my expectation would be that all system containers are upgraded during ros upgrade.

A Y/N switch to include console during ros upgrade or a note at the end of the upgrade command prior to reboot (with a link to console persistence doc) would be the most helpful IMO.

Sample message:

os-console is not upgraded by default - to upgrade after reboot, run sudo ros console switch default. Any files stored outside of persistent directories will be permanently deleted. See https://burmillaos.org/docs/installation/custom-builds/custom-console/#console-persistence

from os.

Should we be instructing users to use ros console enable default after an upgrade instead?

Probably because it is not bug but feature which comes from https://github.com/burmilla/os/blob/v1.9.6/os-config.tpl.yml#L246

In additionally we can instruct users to update that setting to always which should make console non-persistent.

I submitted a PR here: burmilla/burmilla.github.io#21

Unfortunately ros console enable does not force a recreate of the container, so ros console switch is required to recreate/update the os-console container so that's what I included.

from os.

But this is only mentioned under "Upgrade RancherOS to BurmillaOS".
Maybe there should be a mention also under https://burmillaos.org/docs/installation/upgrading/#upgrading-1,
that if you want to use the latest console container you must run sudo ros console switch default.

from os.

Documentation is build from https://github.com/burmilla/burmilla.github.io
Feel free to create pull requests to improve it.

from os.

Documentation is build from https://github.com/burmilla/burmilla.github.io Feel free to create pull requests to improve it.

There's a statement on that page saying "ros console switch has several bugs since RancherOS era, please use “ Enabling consoles” below."

Should we be instructing users to use ros console enable default after an upgrade instead?

from os.

Should we be instructing users to use ros console enable default after an upgrade instead?

Probably because it is not bug but feature which comes from https://github.com/burmilla/os/blob/v1.9.6/os-config.tpl.yml#L246

In additionally we can instruct users to update that setting to always which should make console non-persistent.

from os.

In additionally we can instruct users to update that setting to always which should make console non-persistent.

What I did mean with this one is that it should be possible to use cloud-init like this:

rancher:
  services:
    console:
      labels:
        io.rancher.os.scope: system
        io.rancher.os.after: network
        io.docker.compose.rebuild: "always"
        io.rancher.os.console: default

to overwrite values in os-config.tpl.yml

But that need to be tested if it works correctly and that do we really need set all those labels or will it works fine if user just set value for io.docker.compose.rebuild (might be that other labels disappear from config then).

from os.

But that need to be tested if it works correctly and that do we really need set all those labels or will it works fine if user just set value for io.docker.compose.rebuild (might be that other labels disappear from config then).

Thanks @olljanat - I didn't test/verify that so didn't want to write anymore about it.

from os.

The primary issue I have with a non-persistent console is that I do not know of a cron alternative.

from os.

Way how things works with non-persistent console is that everything needs to be configured with cloud-init. So either use https://burmillaos.org/docs/system-services/custom-system-services/#cron or rc.local or with https://burmillaos.org/docs/configuration/advanced/write-files/

However, things gets quite tricky on that one so perhaps we should use logic where console is rebuild automatically in upgrade but not in reboot.

from os.

It could also be that I just don't know patterns here; I have my cron tasks all containerized, but had difficulty figuring out best practices for a scheduler

from os.

WDYT, should we change console to non-persistent by default in 2.0.0 release version (or RC2 if we release that)?

After all it is very simple one line change to this

os/os-config.tpl.yml

Line 245 in 615b3d4

io.docker.compose.rebuild: "false"

but challenge is that it might be confusing for those who have used to current behavior.

As recap for those who have not followed whole story. In RancherOS, default console was non-persistent but others was persistent and because in #9 we decided to switch to Debian console it did came as persistent.

Let vote. Leave give 👍 if you support changing console to non-persistent and 👎 if you prefer to keep it console persistent by default.

I'm avoiding answering because I don't fully understand the implications. If this is done will there not be any persistent directories at all, or is it just limited to locations provided by the console container (which are...?)...will I need to explicitly create any files under /home in cloud-config instead...etc. I recognize there's not a simple answer so don't expect one but hoping to learn from the discussion :)

from os.

Looks that rebuild is not mandatory anymore in v2.0.0 but user can choose upgrade or not the console so closing this one.

from os.