Make upgrade of major distribution release easier

[ben-grande]

Current problem (if any)

Upgrading templates can be time consuming for the user as it requires manual changes due to Qubes OS lacking a CLI tool to rename qubes.

Consider a Fedora template tpl-mgmt that was based on Fedora 39. To upgrade the template, user has to either do in-place upgrade (dirty) or set the new Fedora version to 40, rename the template using the Qube Manager and then running the formulas that target that template.

Proposed solution

There are two options:

1. Contribute to upstream a CLI tool qvm-rename to rename qubes using as base the same method used in Qubes Manager.

2. Add distribution name and version to qube name, such as tpl-mgmt-fedora-40, tpl-sys-cacher-debian-12.

The first option seems cleaner at first glance, but renaming a qube while a template based qube is running is not easy to handle due to some properties migration, has to shutdown all qubes based on it, AppVMs and DispVMs.

The second option seems dirtier as it would make the naming scheme horrible, the name big, the recreation of all formulas, old templates remains on the system (unused), but that is actually what Qubes OS uses, it releases base templates with a version scheme instead of asking users to rename their templates, they only switch the template preference of qubes to the new template.

The value to a user, and who that user might be

• User: will be benefited by a seamless migration of template major release
• Developer: will be benefited by easier testing of new major distribution releases on a dirty system that already has some templates created by Qusal.

[deeplow]

The first option seems cleaner at first glance, but renaming a qube while a template based qube is running is not easy to handle due to some properties migration, has to shutdown all qubes based on it, AppVMs and DispVMs.

I wonder if there is a 3rd option:

3. Once qvm-template-upgrade is integrated into the GUI updater, Qubes could stop having version numbers in the template's names by default.

With this approach we wouldn't need to be concerned about versions in template names at all.

[ben-grande]

I don't think Qubes will stop having the version in the template name because there are times Qubes supports 2 versions of the same template and the way dnf chooses a version to install is via the version. It is true that qvm-template-upgrade can facilitate the work though, but I find it a "dirty" solution compared to a fresh install, as it can lead to a different package set. I documented this today but didn't link to this issue: https://github.com/ben-grande/qusal/blob/main/docs/INSTALL.md#upgrade-a-template-in-place

…

Message ID: ***@***.***>

[deeplow]

That's a fair point. Although I believe dnf package names are separate from the template's name. On top of that we could have the default templates as just fedora and if the user chooses to do the "non-dirty" solution of installing new templates, they would just get the ones with the names.

It is true that qvm-template-upgrade can facilitate the work though, but I
find it a "dirty" solution compared to a fresh install, as it can lead to a
different package set.

I think the priority must be usability here. It's too much of a burden for regular users to do the "clean" on every new fedora template. IMO inplace upgrades should be the default (if deemed "safe" enough). But advanced usage through the template manager should also be accommodated without regressions.

[ben-grande]

@kennethrrosen Please express what you disagree with using words, then I can better access it. Using emojis does not make it clear what you agree or disagree with (unless you disagree with everything in the post).

@deeplow

That's a fair point. Although I believe dnf package names are separate from the template's name. On top of that we could have the default templates as just fedora and if the user chooses to do the "non-dirty" solution of installing new templates, they would just get the ones with the names.

This should be proposed upstream to QubesOS for wider input and to benefit all downstream projects. Should also happen before R5.0, else it will only possible happen in the other major release R6.0, which is far far away.

I think the priority must be usability here. It's too much of a burden for regular users to do the "clean" on every new fedora template. IMO inplace upgrades should be the default (if deemed "safe" enough). But advanced usage through the template manager should also be accommodated without regressions.

I agree that the final solution must have the best UX. I hope to also make the states clean instead of complicated. See my comment regarding lack of backports to in-place upgrade. This broke every Fedora Minimal Salt state and the workaround is ugly:

qusal/salt/qubes-builder/create.sls

Lines 101 to 121 in 05e73f9

	## TODO: Remove when template with patch reaches upstream or updates enforce
	## salt-deps to be installed.
	## https://github.com/QubesOS/qubes-issues/issues/8806
	"{{ slsdotpath }}-install-salt-deps":
	cmd.script:
	- require:
	- qvm: "{{ slsdotpath }}-set-management_dispvm-to-dvm-fedora"
	- name: salt-patch.sh
	- source: salt://fedora-minimal/files/admin/bin/salt-patch.sh
	- args: tpl-{{ slsdotpath }}
	## TODO: Remove when template with patch reaches upstream or updates enforce
	## salt-deps to be installed.
	## https://github.com/QubesOS/qubes-issues/issues/8806
	"{{ slsdotpath }}-shutdown-template":
	qvm.shutdown:
	- require:
	- cmd: "{{ slsdotpath }}-install-salt-deps"
	- name: tpl-{{ slsdotpath }}
	- flags:
	- force

qusal/salt/qubes-builder/prefs.sls

Lines 7 to 20 in 05e73f9

	## TODO: Remove when template with patch reaches upstream or updates enforce
	## salt-deps to be installed.
	## https://github.com/QubesOS/qubes-issues/issues/8806
	include:
	- .create
	"{{ slsdotpath }}-set-management_dispvm-to-default":
	qvm.vm:
	- require:
	- cmd: "{{ slsdotpath }}-install-salt-deps"
	- name: tpl-{{ slsdotpath }}
	- prefs:
	- management_dispvm: "*default*"

In-place upgrade would not fix this issue, only redownloading the new packaged template would. Which is also something that I don't enforce, as this was the first time I saw a breaking issue on the same template version but with different release dates.

[deeplow]

That's a fair point. Although I believe dnf package names are separate from the template's name. On top of that we could have the default templates as just fedora and if the user chooses to do the "non-dirty" solution of installing new templates, they would just get the ones with the names.

This should be proposed upstream to QubesOS for wider input and to benefit all downstream projects. Should also happen before R5.0, else it will only possible happen in the other major release R6.0, which is far far away.

Will do.

[kennethrrosen]

@kennethrrosen Please express what you disagree with using words, then I can better access it. Using emojis does not make it clear what you agree or disagree with (unless you disagree with everything in the post).

@deeplow covered it! Thanks, all.