Ability to hide (a) qube(s) from updates

[EdGeraghty]

The problem you're addressing (if any)

I have several qubes which are never going to receive updates - currently these qubes are visible in the update manager, but they are clutter

The solution you'd like

The ability to hide (a) qube(s) from the updating functionality

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

It means we can select all in the update manager rather than having to choose qubes individually. This will benefit anyone running a Windows 10/11 HVM, TempleOS, or a number of other guests such as the mirage-os unikernel.

[jamke]

Some binary prefs like disable_updates came be added to qubes to manage this feature. Looks useful as some qubes (offline) with fixed version of software can indeed be expected not to be updated.

[deeplow]

I wonder if this is what the updateable preference is for. The docs don't clarify much about the intended purpose:

updateable
True if this machine may be updated on its own.

However it cannot be changed by the user. I wonder what the reasoning is (maybe footshooting prevention).

[user@dom0 ~]$ qvm-prefs fedora-39-xfce updateable False
qvm-prefs: error: property 'updateable' on TemplateVM instance cannot be set

[alimirjamali]

Ok. This issue is relatively easy to solve. I am going to work on this. The design is going to be like this:

• A new boolean feature named skip-update (or similar) could be allocated for this (reusing the updateable pref is not recommended since the Template might be indeed updateable but user wants to skip updating it temporary).
• vmupdate library should be updated to honour the above feature.
• GKT tools (The GUI Updater & Qubes Update systray widget) should be updated to honour the above feature.
• Qt GUI tools (Qube Manager) should be updated to honour the above feature.

Overall it is very simple. But more than one PR will be necessary.

p.s.: Since this will be an advanced feature and niche area which is most probably not used by most users, I believe it is better to avoid adding it to qubes-vm-settings dialog. Advanced users could use the CLI to change the feature.

[deeplow]

Nice! Happy to see some momentum on this.

A new boolean feature named skip-update (or similar)

Meta question: should this be a feature or a preference? updatable is a preference and not a feature.

I often confused both, but in my head qube preferences are well defined whereas as features are more open-ended. In particular (especially if something that exists natively -- like this case), with preferences one can list / discover all available by running qvm-prefs [vmname] --help-properties. Otherwise users will have to happen to come across this option in the docs somewhere.

Anyways, just my two cents. I may be wrong on the distinction, though.

[marmarek]

Meta question: should this be a feature or a preference? updatable is a preference and not a feature.

This is a very good question :) We don't have any guidelines for this, and we don't use it consistently really (*)...
The updatable property is really a read-only property more or less meaning if root volume is persistent ("does it make sense to install updates there"). And this too may be misleading when the updating mechanism will support flatpaks installed in the user home in the future.
The properties and features can have a bit different set of behaviors:

• properties:
  • can be listed in qvm-prefs
  • can have custom setter that validates the value, and possibly transform it
  • can have an arbitrary mechanics for default value (like calculated based on other properties, different for different qube type etc)
  • properties are cached, and needs to handle cache invalidation properly (especially tricky for default value that is calculated based on other properties)
• features:
  • just simple key+value, usually value is just boolean (empty for false, "1" for true)
  • few predefined inheritance methods (take default from template, from netvm, from guivm)
  • default value is "feature not set", up for its user to define what that means
  • no validation on setting, no detection for typos in the feature name etc

Generally, properties are smarter. But due to its stricter nature, and potentially smarter behavior, need more care when implementing. This also means committing to its support in the future, converting on upgrades, while restoring old backups in the future etc. More or less it means you cannot really remove it in the future - at least some migration code needs to stay forever.

There was a plan to make features a bit smarter, especially around their documentation and value validation (basically have an API that allows adding extra metadata to some feature names). But that mechanism never materialized and the only thing we have is the qvm-features man page.

In this particular case, I think it's okay to go with a feature, especially since updates-available is a feature already and is yet another factor for selecting what to update. But if you'd prefer to make it a property, I would be okay with that too.

(*) one one hand backup_timestamp or keyboard_layout are properties, which aren't really part of core mechanism, but on the other hand, memory-hotplug, video-model or uefi are features but their implementation is deeply integrated into core-admin component.

[deeplow]

That makes sense. Thanks a lot for the clarification. Feature it is :)