https://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842022-09-22T09:32:51ZopenSUSE Project Management ToolopenQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5561502022-09-22T09:32:51Zpcervinkapcervinka@suse.com
<ul><li><strong>Project</strong> changed from <i>openQA Tests</i> to <i>175</i></li><li><strong>Category</strong> deleted (<del><i>Refactor/Code Improvements</i></del>)</li></ul> openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5561952022-09-22T10:50:38ZMDouchamartin.doucha@suse.com
<ul></ul><p>pcervinka wrote:</p>
<blockquote>
<a name="1-Universal-function-for-package-installation"></a>
<h5 >1. Universal function for package installation<a href="#1-Universal-function-for-package-installation" class="wiki-anchor">¶</a></h5>
<p>Example in test code:</p>
<pre><code>$testapi::distri->get_package_manager()->install_package("ltp")
</code></pre>
<p>As you can see, test code just contained universal installation command, which was distro independent.</p>
</blockquote>
<p>This could be simplified to just <code>install_package("ltp");</code> and all the <code>$testapi::distri->get_package_manager()</code> boilerplate should be hidden inside the <code>install_package()</code> helper function.</p>
<blockquote>
<a name="2-Existing-trup_call-function-needs-root-console"></a>
<h5 >2. Existing <code>trup_call</code> function needs <code>root-console</code><a href="#2-Existing-trup_call-function-needs-root-console" class="wiki-anchor">¶</a></h5>
<p>It means that code with <code>$self->select_serial_terminal</code> doesn't work, console change needs to be done.</p>
<p>You can find this pattern in the code:</p>
<pre><code>select_console 'root-console';
trup_call("--continue pkg $cmd", timeout => 2000);
</code></pre>
<p>Is there a way to fix that? <code>trup_call</code> should be console independent.</p>
</blockquote>
<p>Yes, this can be fixed, although it'd be easier to fix (or even write correctly from the start) if the console API design were sane.</p>
<blockquote>
<a name="3-Support-for-transactional-command-in-script_run"></a>
<h5 >3. Support for transactional command in script_run<a href="#3-Support-for-transactional-command-in-script_run" class="wiki-anchor">¶</a></h5>
<p>We can run commands on the transaction system in the snapshot via <code>transactional-update -c -d --quiet run</code>.<br>
For example, we install something, want to just check something , but we can't use normal <code>script_run</code>, because it will run on booted snapshot.</p>
<p>Would be worth to have something like <code>script_run("COMMAND", transactional => [is_transactional| any other condition | 1])</code> which would wrap command in case we want transactional approach?</p>
</blockquote>
<p>This should be handled by <code>trup_call()</code>. When that function is called on a non-transactional system, it should fall back to plain <code>script_run()</code>.</p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5576262022-09-27T09:32:03Zszarate
<ul><li><strong>Related to</strong> <i><a class="issue tracker-4 status-6 priority-4 priority-default closed child parent behind-schedule" href="/issues/115196">action #115196</a>: [qe-core] Prepare for ALP - Schedule Databases testsuite for ALP</i> added</li></ul> openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5578002022-09-27T15:32:02Zszarate
<ul></ul><p>MDoucha wrote:</p>
<blockquote>
<p>pcervinka wrote:</p>
<blockquote>
<a name="1-Universal-function-for-package-installation"></a>
<h5 >1. Universal function for package installation<a href="#1-Universal-function-for-package-installation" class="wiki-anchor">¶</a></h5>
<p>Example in test code:</p>
<pre><code>$testapi::distri->get_package_manager()->install_package("ltp")
</code></pre>
<p>As you can see, test code just contained universal installation command, which was distro independent.</p>
</blockquote>
<p>This could be simplified to just <code>install_package("ltp");</code> and all the <code>$testapi::distri->get_package_manager()</code> boilerplate should be hidden inside the <code>install_package()</code> helper function.</p>
</blockquote>
<p>What I had thought about this, is to use module flags, and the <code>pre_run</code> hooks, and do the installation of packages there, so that test modules could declare in a hash which packages it expects to have installed, and through an install wrapper use directly the abstract factory: <code>$testapi::distri->packages->install(qw(ltp vim))</code>, and if needed use a facade for further needs... </p>
<blockquote>
<blockquote>
<a name="2-Existing-trup_call-function-needs-root-console"></a>
<h5 >2. Existing <code>trup_call</code> function needs <code>root-console</code><a href="#2-Existing-trup_call-function-needs-root-console" class="wiki-anchor">¶</a></h5>
<p>It means that code with <code>$self->select_serial_terminal</code> doesn't work, console change needs to be done.</p>
<p>You can find this pattern in the code:</p>
<pre><code>select_console 'root-console';
trup_call("--continue pkg $cmd", timeout => 2000);
</code></pre>
<p>Is there a way to fix that? <code>trup_call</code> should be console independent.</p>
</blockquote>
<p>Yes, this can be fixed, although it'd be easier to fix (or even write correctly from the start) if the console API design were sane.</p>
</blockquote>
<p>Which console api in this case?</p>
<blockquote>
<blockquote>
<a name="3-Support-for-transactional-command-in-script_run"></a>
<h5 >3. Support for transactional command in script_run<a href="#3-Support-for-transactional-command-in-script_run" class="wiki-anchor">¶</a></h5>
<p>We can run commands on the transaction system in the snapshot via <code>transactional-update -c -d --quiet run</code>.<br>
For example, we install something, want to just check something , but we can't use normal <code>script_run</code>, because it will run on booted snapshot.</p>
<p>Would be worth to have something like <code>script_run("COMMAND", transactional => [is_transactional| any other condition | 1])</code> which would wrap command in case we want transactional approach?</p>
</blockquote>
<p>This should be handled by <code>trup_call()</code>. When that function is called on a non-transactional system, it should fall back to plain <code>script_run()</code>.</p>
</blockquote>
<p>hmm... @Petr, here you mean any particular call to script_run, or any? for the earlier I'd go with what Martin suggests, for the latter, we might want to think a bit further... of course we could make script_run redefined in the test distribution, to be aware of a system being transactional or not, and whether we want it quiet or not for a given test module...</p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5591622022-10-03T08:45:00ZMDouchamartin.doucha@suse.com
<ul></ul><p>szarate wrote:</p>
<blockquote>
<p>MDoucha wrote:</p>
<blockquote>
<p>Yes, this can be fixed, although it'd be easier to fix (or even write correctly from the start) if the console API design were sane.</p>
</blockquote>
<p>Which console api in this case?</p>
</blockquote>
<p>All of it, from the public <code>testapi</code> functions all the way down to the backends.</p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5599872022-10-05T07:43:13Zpcervinkapcervinka@suse.com
<ul></ul><p>MDoucha wrote:</p>
<blockquote>
<p>szarate wrote:</p>
<blockquote>
<p>MDoucha wrote:</p>
<blockquote>
<p>Yes, this can be fixed, although it'd be easier to fix (or even write correctly from the start) if the console API design were sane.</p>
</blockquote>
<p>Which console api in this case?</p>
</blockquote>
<p>All of it, from the public <code>testapi</code> functions all the way down to the backends.</p>
</blockquote>
<p><a class="user active user-mention" href="https://progress.opensuse.org/users/17668">@okurz</a> are you aware of any plans or ideas which could help?</p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5599902022-10-05T07:52:24Zpcervinkapcervinka@suse.com
<ul></ul><p>szarate wrote:</p>
<blockquote>
<p>MDoucha wrote:</p>
<blockquote>
<p>pcervinka wrote:</p>
<blockquote>
<a name="3-Support-for-transactional-command-in-script_run"></a>
<h5 >3. Support for transactional command in script_run<a href="#3-Support-for-transactional-command-in-script_run" class="wiki-anchor">¶</a></h5>
<p>We can run commands on the transaction system in the snapshot via <code>transactional-update -c -d --quiet run</code>.<br>
For example, we install something, want to just check something , but we can't use normal <code>script_run</code>, because it will run on booted snapshot.</p>
<p>Would be worth to have something like <code>script_run("COMMAND", transactional => [is_transactional| any other condition | 1])</code> which would wrap command in case we want transactional approach?</p>
</blockquote>
<p>This should be handled by <code>trup_call()</code>. When that function is called on a non-transactional system, it should fall back to plain <code>script_run()</code>.</p>
</blockquote>
<p>hmm... @Petr, here you mean any particular call to script_run, or any? for the earlier I'd go with what Martin suggests, for the latter, we might want to think a bit further... of course we could make script_run redefined in the test distribution, to be aware of a system being transactional or not, and whether we want it quiet or not for a given test module...</p>
</blockquote>
<p>This particular case, i sorted for short term, but there could be better generic solution. This one just uses <code>script_output</code>, idea is the same:<br>
<a href="https://github.com/czerw/os-autoinst-distri-opensuse/blob/b53828660d486122b2bbc298ab3a791c50e95cbf/lib/bootloader_setup.pm#L144" class="external">https://github.com/czerw/os-autoinst-distri-opensuse/blob/b53828660d486122b2bbc298ab3a791c50e95cbf/lib/bootloader_setup.pm#L144</a><br>
<a href="https://github.com/czerw/os-autoinst-distri-opensuse/blob/b53828660d486122b2bbc298ab3a791c50e95cbf/lib/bootloader_setup.pm#L163" class="external">https://github.com/czerw/os-autoinst-distri-opensuse/blob/b53828660d486122b2bbc298ab3a791c50e95cbf/lib/bootloader_setup.pm#L163</a></p>
<p>It could be any call, but maybe, i just want to generalize specific case, which is not need for wider use.</p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5648142022-10-19T07:26:08Zokurzokurz@suse.com
<ul></ul><p>pcervinka wrote:</p>
<blockquote>
<p><a class="user active user-mention" href="https://progress.opensuse.org/users/17668">@okurz</a> are you aware of any plans or ideas which could help?</p>
</blockquote>
<p>I do not know about any further plans or ideas regarding this going beyond this ticket itself.</p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5648232022-10-19T07:27:07Zjstehlik
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Workable</i></li></ul><p>Followup to be planned beginning of November.</p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5649042022-10-19T08:36:47ZMDouchamartin.doucha@suse.com
<ul></ul><p>pcervinka wrote:</p>
<blockquote>
<a name="1-Universal-function-for-package-installation"></a>
<h5 >1. Universal function for package installation<a href="#1-Universal-function-for-package-installation" class="wiki-anchor">¶</a></h5>
</blockquote>
<p>Related PR: <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15683" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15683</a></p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5698752022-11-02T08:51:04Zjstehlik
<ul><li><strong>Project</strong> changed from <i>175</i> to <i>openQA Tests</i></li><li><strong>Assignee</strong> set to <i>pcervinka</i></li></ul><p>Petr and Santi have scheduled a call on this. To be moved into another project.</p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5771712022-11-23T08:00:09Zszarate
<ul></ul><p>Some of the Thoughts I shared with Petr, 2 weeks ago:</p>
<p>thinking for instance in how the transnational update module will work, one can have a pre run module that looks for a packages method which should return a list of packages that the system under test should install, when it is found, it is passed directly to the install_packages() function, which defined in opensusedistribution, should allow for managing different types of installers, via InstallerFactory pattern (or maybe some other), the important part, is to be able to ask <code>$distri->action($packages)</code></p>
<p>on test teardown, system is either rolled back in cases where btrfs is being used and it’s possible, or restored to a previous snapshot (ideally) when it’s a transactional system</p>
<p>it’s also posible that for isotovideo, a new step might be needed to achieve that, so that <code>basetest::setup</code> and <code>basetest::teardown</code> methods exist, and are capable somehow, of producing junit compatible output, this with the idea of having openqa test runs, to integrate with other systems, and to be able. to have standard interface that allows the reviewer to have better info ob the test that have been executed</p>
<p>questions arise when looking into the state of needles or what to do with them, but it should not be a huge problem in the end</p>
<p>the flag <code>$basetest::packages</code> has to be a hash, or a dictionary that allows the caller to know what the test objects are going to be</p>
<p>Petr's suggestion is to: Consider installing everything from the beginning before the tests are executed</p>
<p>so in the end, we’re defining:</p>
<ul>
<li>setup</li>
<li>teardown</li>
<li>objects</li>
</ul>
<p>This also would help us to avoid post_fail_hooks that have mixed roles, such as <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/saltbase.pm#L135" class="external">stopping services and collecting logs</a></p>
<p>With this, as a further step one should be able to easily write either a <code>Perl::Tidy</code> rule or a <code>Perl::Critic</code> check, that allows for verification of such things, like: no package install if testobjects are defined</p>
<p>We can continue this work on a new ticket, in the qe-core backlog, with the help of the rest of the teams</p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5801592022-12-01T11:14:15Zpcervinkapcervinka@suse.com
<ul></ul><p>Above idea looks fine, but we should make some follow up for details, as other ideas are already poping up <a href="https://github.com/pablo-herranz/os-autoinst-distri-opensuse/blob/9ea1f81305648b0fad9dfdab70f80dd46417737e/lib/Wrappers/packages.pm" class="external">https://github.com/pablo-herranz/os-autoinst-distri-opensuse/blob/9ea1f81305648b0fad9dfdab70f80dd46417737e/lib/Wrappers/packages.pm</a></p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5801622022-12-01T11:14:31Zpcervinkapcervinka@suse.com
<ul><li><strong>Assignee</strong> deleted (<del><i>pcervinka</i></del>)</li></ul> openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=5980712023-02-01T16:57:00Zszarate
<ul><li><strong>Category</strong> set to <i>Refactor/Code Improvements</i></li></ul> openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=6088732023-03-03T11:55:15Zszarate
<ul><li><strong>Tags</strong> changed from <i>alp, slem</i> to <i>alp, slem, platform-team</i></li><li><strong>Tracker</strong> changed from <i>action</i> to <i>coordination</i></li><li><strong>Subject</strong> changed from <i>[kernel][core][alp] Possible improvements for transactional installations</i> to <i>[qe-core] Possible improvements for transactional installations</i></li><li><strong>Status</strong> changed from <i>Workable</i> to <i>New</i></li></ul><p>See suggestion from: <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/16506#discussion_r1121460485" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/16506#discussion_r1121460485</a></p>
<ul>
<li>Ideally, the creation of users can also be delegated to the setup step of the testsuite.</li>
</ul>
<p>I had thought down a much better idea yesterday but forgot to write it down, so I better leave it here for posterity</p>
<p>PS: taking the ticket for QE-Core and will coordinate from there once the time comes</p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=6090262023-03-04T12:20:31Zjlausuchjalausuch@suse.com
<ul></ul><p>I like the idea of this ticket, then we can avoid those if-elses everywhere.<br>
However, we need to tweak <code>check_reboot_changes</code> as it will fail if the package is already installed as it expects a change in the new snapshot created by <code>transactional-update</code>. I guess it's easy to change that behaviour.<br>
There is another thing to avoid this, which is using <code>process_reboot</code> after pkg installation, but it will reboot always regardless if the package is installed or not. </p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=6899242023-10-24T09:01:45Zpcervinkapcervinka@suse.com
<ul></ul><p>Was updating maintenance part for kernel update recently and there is one outcome. <code>transactional-update patch</code> don't indicate return code for a need of another patch <br>
round if there is package manager update. It just prints it in output, but this is not comfortable as with zypper (which has multiple error codes). I created <a href="https://bugzilla.suse.com/show_bug.cgi?id=1216504" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1216504</a> for further discussion. <a class="user active user-mention" href="https://progress.opensuse.org/users/25856">@jlausuch</a> im just wondering, why it was not discovered earlier? For example why function <code>fully_patch_system</code> was not adapted already for transactional systems, as it is function used across all maintenance tests. Adaptation is now done in <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18012" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18012</a>.</p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=6945652023-10-31T11:04:28Zdzedrojpupava@suse.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>Assignee</strong> set to <i>dzedro</i></li></ul> openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=6955132023-11-02T16:34:25Zjlausuchjalausuch@suse.com
<ul></ul><p>pcervinka wrote in <a href="#note-19">#note-19</a>:</p>
<blockquote>
<p>Was updating maintenance part for kernel update recently and there is one outcome. <code>transactional-update patch</code> don't indicate return code for a need of another patch <br>
round if there is package manager update. It just prints it in output, but this is not comfortable as with zypper (which has multiple error codes). I created <a href="https://bugzilla.suse.com/show_bug.cgi?id=1216504" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1216504</a> for further discussion. <a class="user active user-mention" href="https://progress.opensuse.org/users/25856">@jlausuch</a> im just wondering, why it was not discovered earlier? For example why function <code>fully_patch_system</code> was not adapted already for transactional systems, as it is function used across all maintenance tests. Adaptation is now done in <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18012" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18012</a>.</p>
</blockquote>
<p>Not sure... The way we have always installed updates (aggregates and incidents) has been like this:<br>
<a href="https://openqa.suse.de/tests/12746599#step/install_updates/341" class="external">https://openqa.suse.de/tests/12746599#step/install_updates/341</a><br>
e.g. </p>
<pre><code>zypper -n --no-gpg-checks ar -f -n 'TEST_0' http://download.suse.de/ibs/SUSE:/Maintenance:/29290/SUSE_Updates_SLE-Micro_5.5_x86_64/ 'TEST_0'
zypper -n ref
...
zypper -n --no-gpg-checks ar -f -n 'TEST_25' http://download.suse.de/ibs/SUSE:/Maintenance:/31370/SUSE_Updates_SLE-Micro_5.5_x86_64/ 'TEST_25'
zypper -n ref
transactional-update -n up
</code></pre> openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=7335712023-11-14T09:47:47Zszarate
<ul><li><strong>Tags</strong> changed from <i>alp, slem, platform-team</i> to <i>alp, slem, platform-team, qe-core-november-sprint</i></li></ul> openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=7378672023-11-24T11:47:56Zdzedrojpupava@suse.com
<ul></ul><p>Is there test I could use to test the wrapper, I tried live patching <a href="https://dzedro.suse.cz/tests/146#step/qa_test_klp/17" class="external">https://dzedro.suse.cz/tests/146#step/qa_test_klp/17</a><br>
Ignoring the missing packages, I guess live patching with transactional update is not even possible, because you have to do reboot to apply changes.<br>
I'm looking for some, but transactional tests are separated and shared tests which I checked don't do install.</p>
<p>edit: found tests/kernel/update_kernel.pm from PR in comments</p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=7384992023-11-27T12:59:52Zszarate
<ul><li><strong>Sprint</strong> set to <i>QE-Core: November Sprint 23 (Nov 15 - Dec 13)</i></li></ul> openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=7385532023-11-27T13:23:49Zdzedrojpupava@suse.com
<ul></ul><p>cypr ? <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18204" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/18204</a></p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=7388712023-11-28T06:46:14Zpcervinkapcervinka@suse.com
<ul></ul><p>jlausuch wrote in <a href="#note-21">#note-21</a>:</p>
<blockquote>
<p>transactional-update -n up</p>
</blockquote>
<p>I believe, we should use <code>patch</code>, instead of <code>up</code> to validate particular update.</p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=7396842023-11-29T09:31:25Zpcervinkapcervinka@suse.com
<ul></ul><p>Also patch in transactional-update doesn't properly work in case, when is a need for additional restart after package manager update. zypper handles this case, but not via transactional-update. See <a href="https://bugzilla.suse.com/show_bug.cgi?id=1216504" class="external">https://bugzilla.suse.com/show_bug.cgi?id=1216504</a></p>
openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=7438692023-12-11T09:31:14Zszarate
<ul><li><strong>Tracker</strong> changed from <i>coordination</i> to <i>action</i></li></ul> openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=7459832023-12-15T08:56:31Zszarate
<ul><li><strong>Sprint</strong> changed from <i>QE-Core: November Sprint 23 (Nov 15 - Dec 13)</i> to <i>QE-Core: December Sprint 23 (Dec 13 - Jan 10)</i></li></ul> openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=7460412023-12-15T09:29:36Zszarate
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul> openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=7535922024-01-18T11:08:47Zdzedrojpupava@suse.com
<ul><li><strong>Related to</strong> <i><a class="issue tracker-4 status-1 priority-4 priority-default" href="/issues/153865">action #153865</a>: [qe-core] install_package with trup_reboot will fail if package is installed</i> added</li></ul> openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=7579242024-01-31T08:14:02Zszarate
<ul><li><strong>Sprint</strong> changed from <i>QE-Core: December Sprint 23 (Dec 13 - Jan 10)</i> to <i>QE-Core: February Sprint 24 (Jan 31 - Feb 28)</i></li></ul> openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=7581312024-01-31T09:49:44Zszarate
<ul><li><strong>Target version</strong> set to <i>QE-Core: Ready</i></li></ul> openQA Tests - action #117028: [qe-core] Possible improvements for transactional installationshttps://progress.opensuse.org/issues/117028?journal_id=7713222024-03-06T08:35:22Zmgrifalconi
<ul><li><strong>Sprint</strong> changed from <i>QE-Core: February Sprint 24 (Jan 31 - Feb 28)</i> to <i>QE-Core: March Sprint 24 (Mar 06 - Mar 28)</i></li></ul>