Deferred template - #870
ben-grande wants to merge 5 commits into
Conversation
140acbf to
b6ac856
Compare
b6ac856 to
58390cc
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #870 +/- ##
==========================================
+ Coverage 70.51% 70.77% +0.26%
==========================================
Files 61 61
Lines 14371 14366 -5
==========================================
+ Hits 10133 10168 +35
+ Misses 4238 4198 -40
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
58390cc to
47891a2
Compare
With a server that supports deferred template, clients don't need to worry about the qube state to block template change, in this case, there were only things to remove, as showing "active_template" is irrelevant here, the user just wants to change the "template" property to a new value. For: QubesOS/qubes-issues#8070 Requires: QubesOS/qubes-core-admin#870 Requires: QubesOS/qubes-core-admin-client#496
47891a2 to
ed9d40b
Compare
|
openQArun PR_LABEL=openqa-group-2 |
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026083116-devel&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026050504-devel&flavor=update
Failed tests13 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/176874#dependencies 34 fixed
Unstable testsDetails
Performance TestsPerformance degradation:19 performance degradations
Remaining performance tests:92 tests
|
With the introduction of deferred templates, the "active_template" should be preferred in favor of the "template" property. For: QubesOS/qubes-issues#8070 Requires: QubesOS/qubes-core-admin#870
With the introduction of deferred templates, the "active_template" should be preferred in favor of the "template" property. For: QubesOS/qubes-issues#8070 Requires: QubesOS/qubes-core-admin#870
ed9d40b to
058add5
Compare
With a server that supports deferred template, clients don't need to worry about the qube state to block template change, in this case, there were only things to remove, as showing "active_template" is irrelevant here, the user just wants to change the "template" property to a new value. For: QubesOS/qubes-issues#8070 Requires: QubesOS/qubes-core-admin#870 Requires: QubesOS/qubes-core-admin-client#496
Add ability for template based qubes (AppVM and DispVM) to be able to change the template while running. When the qube is running and you modify the "template" property, it is set to the "newvalue", while the "active_template" changes to the "oldvalue" if it is still the default. The use of separate properties doesn't break new clients. For example, Qube Manager reacts to "property-set:template" and adapts the field to the current value, despite it not being the active one. This is what happens for other properties also, such as "virt_mode" and "kernel", you may change it live, but it only applies on the next boot. Fixes: QubesOS/qubes-issues#8070
Until the template has changed, querying features from the active template is saner, as the qube has the volume from the template, and that affects many calls, such as "vmexec", "supported-rpc.*", "os-version" and many others. Having the option to disable query of "active_template" and go straight to "template" is necessary when when want values that would only be relevant on the next boot.
|
https://openqa.qubes-os.org/tests/192952#step/TC_00_Basic/19
# test_300_deferred_template
# failure:
# timestamp 2026-08-19T15:29:38.593611
Traceback (most recent call last):
File "/usr/lib64/python3.13/contextlib.py", line 85, in inner
return func(*args, **kwds)
File "/usr/lib/python3.13/site-packages/qubes/tests/integ/basic.py", line 590, in test_300_deferred_template
self.loop.run_until_complete(self._test_300_deferred_template())
~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.13/asyncio/base_events.py", line 725, in run_until_complete
return future.result()
~~~~~~~~~~~~~^^
File "/usr/lib/python3.13/site-packages/qubes/tests/integ/basic.py", line 600, in _test_300_deferred_template
await self.defer_tpl(appvm)
File "/usr/lib/python3.13/site-packages/qubes/tests/__init__.py", line 1790, in defer_tpl
check_deferred(qube, active=template, deferred=template)
~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.13/site-packages/qubes/tests/__init__.py", line 1770, in check_deferred
self.assertEqual(get_tpl_vol_vid(qube), get_tpl_vol_path(active))
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 'fedora-44-xfce-pool/root' != 'vm-fedora-44-xfce-pool-root'
- fedora-44-xfce-pool/root
? ^
+ vm-fedora-44-xfce-pool-root
? +++ ^Different fs are having different names here... I need to compare the volume vid and the path differently... |
097d063 to
c3582b3
Compare
I didn't find an easy way to compare. Technically, each pool type should have the same method to query it's format, by providing the qube name and volume name, and then it returns the volume string. I also noticed the pools are switched by OpenQA, so there isn't a test doing that that I can run locally, well, I could copy the whole pool switch code... I ended up checking each pool volume format, and just ThinPool for LVM uses a certain format with |
|
openQArun PR_LABEL=openqa-group-2 |
|
Can't you simply take properties of relevant volume objects instead of building the id manually? |
c3582b3 to
4c8fbb0
Compare
|
openQArun PR_LABEL=openqa-group-2 |
With the introduction of deferred templates, the "active_template" should be preferred in favor of the "template" property. For: QubesOS/qubes-issues#8070 Requires: QubesOS/qubes-core-admin#870
With the introduction of deferred templates, the "active_template" should be preferred in favor of the "template" property. For: QubesOS/qubes-issues#8070 Requires: QubesOS/qubes-core-admin#870
With the introduction of deferred templates, the "active_template" should be preferred in favor of the "template" property. For: QubesOS/qubes-issues#8070 Requires: QubesOS/qubes-core-admin#870
With the introduction of deferred templates, the "active_template" should be preferred in favor of the "template" property. For: QubesOS/qubes-issues#8070 Requires: QubesOS/qubes-core-admin#870
With the introduction of deferred templates, the "active_template" should be preferred in favor of the "template" property. For: QubesOS/qubes-issues#8070 Requires: QubesOS/qubes-core-admin#870
With the introduction of deferred templates, the "active_template" should be preferred in favor of the "template" property. For: QubesOS/qubes-issues#8070 Requires: QubesOS/qubes-core-admin#870
With the introduction of deferred templates, the "active_template" should be preferred in favor of the "template" property. For: QubesOS/qubes-issues#8070 Requires: QubesOS/qubes-core-admin#870
|
openQArun PR_LABEL=openqa-group-2 |
|
I don't see the pipeline in neither: |
3 participants
Add ability for template based qubes (AppVM and DispVM) to be able to change the template while running. When the qube is running and you modify the
templateproperty, it is set to thenewvalue, while theactive_templatechanges to theoldvalueif it is still the default.The use of separate properties doesn't break new clients. For example, Qube Manager reacts to
property-set:templateand adapts the field to the current value, despite it not being the active one. This is what happens for other properties also, such asvirt_modeandkernel, you may change it live, but it only applies on the next boot.Fixes: QubesOS/qubes-issues#8070
Clients should deal with the new property this way:
property-(re)?set:(active_)?template)active_templateproperty is default, show only it, else, show it alongside thetemplateindicating that it is deferred, this is for a minimal view with less clutter. On clients that would be better to show two columns containing both values, that is also fine.