Bug 1194989 - [RFE] Provide option to remove / replace base template while template sub-version exists
Summary: [RFE] Provide option to remove / replace base template while template sub-ver...
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.0
Hardware: All
OS: Linux
Target Milestone: ovirt-4.0.0-alpha
: 4.0.0
Assignee: jniederm
QA Contact: sefi litmanovich
: 1209892 1321078 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2015-02-21 17:16 UTC by Jaison Raju
Modified: 2019-11-14 06:46 UTC (History)
19 users (show)

Fixed In Version: ovirt 4.0.0 alpha1
Doc Type: Enhancement
Doc Text:
Previously, it was only possible to remove a base template if there was no template sub-version based upon it. This update allows the removal of a base template, even if there are template sub-versions based upon it. The sub-version with lowest version number becomes the next base template for all other sub-versions. Version numbers are not affected meaning that the version number of the base template no longer needs to be 1.
Clone Of:
Last Closed: 2016-08-23 20:23:09 UTC
oVirt Team: Virt
Target Upstream Version:
sherold: Triaged+

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1362853 0 None None None Never
Red Hat Product Errata RHEA-2016:1743 0 normal SHIPPED_LIVE Red Hat Virtualization Manager 4.0 GA Enhancement (ovirt-engine) 2016-09-02 21:54:01 UTC
oVirt gerrit 47373 0 master MERGED core: Removing base templates (backend part) 2020-07-30 14:32:06 UTC
oVirt gerrit 47374 0 master MERGED core: Removing base templates (db part) 2020-07-30 14:32:06 UTC

Comment 1 Jaison Raju 2015-02-21 17:19:06 UTC
Hello Team,

Please feel free to provide suggestion to implement this feature.
The main objective of this feature is to reclaim the space used by the base
template , if it is not in used or is to be removed .

Jaison R

Comment 3 Michal Skrivanek 2015-06-05 12:13:33 UTC
This bug did not make it in time for 3.6 release, moving out

Comment 4 Michal Skrivanek 2015-09-01 07:15:23 UTC
proposed implementation:

take a cluster lock
change all child templates' parent to the new(oldest) child
change all VMs using "latest" to the new parent (CAD should handle the case when some VM is specifically using the template which is being removed)
release lock
remove the template

if removing fails we won't revert - the template will become a standalone one

Comment 5 Michal Skrivanek 2015-09-01 07:16:26 UTC
*** Bug 1209892 has been marked as a duplicate of this bug. ***

Comment 6 Michal Skrivanek 2016-03-25 05:57:48 UTC
*** Bug 1321078 has been marked as a duplicate of this bug. ***

Comment 7 sefi litmanovich 2016-04-07 10:12:12 UTC
Tested with ovirt-engine-4.0.0-0.0.master.20160405102116.git3819ab7.el7.centos.noarch.

1. I can verify that the deletion of base template works as expected - > next version will become new base.

2. I will write a test plan for this RFE to cover more flows.

3. Some first thoughts and findings:
a. Versions numbering in template menu: If I had 3 version -> base, (2), (3)  and I removed base then I'll stay with base, (3). In my opinion all further numbers should be decreased by 1, so I'll end up with base, (2).

b. Versions numbering in new VM/VmPool menu: basically the same thing, here the result is that in the template drop down you will see the "new" base version still as version (2) (or whatever version it was before).

c. Import/Export options - With the old behaviour one could not export a later version without the base version first being exported, and same goes for importing version, does this RFE means we want to change that flow as well so user can import/export any version at any given time?

Comment 8 jniederm 2016-04-07 10:51:43 UTC
regarding 3a, 3b: Current way of numbering gives users a persistent reference to particular template - each template can be referenced by couple: name (~ base name) and version no matter who many preceding versions were deleted. It also follows the numbering style used before this patch to deal with deletion of non-base templates. Suppose there was a row (base)-(1)-(2)-(3) and template version (2) was deleted. It resulted intto (base)-(1)-(3).
If you think it would be more useful to keep the numbering always continuous and starting by 1 (base), please file a separate bug.

regarding 3c: I can confirm that a template the base template of which was deleted can't be exported. Please file that problem in separate bug.

Comment 9 sefi litmanovich 2016-04-07 11:48:48 UTC
3a, 3b - I really don't know, intuitively I feel that it makes more sense, but basically it's not a very critical thing, I can open an RFE and open it for discussion there.

3c - You mean that after deleting base template, you failed to export the "new" base template which was previously version (2) e.g.?
Because I hit the following bug regardless to version - https://bugzilla.redhat.com/show_bug.cgi?id=1324799

Comment 10 jniederm 2016-04-07 12:12:32 UTC
3c - The problem seems to be indeed in bug 1324799. Having 'Force override' checked I can export any template (without deleted base, with deleted base, template that become base after predecessor deletion). Nevertheless if there is any other problem regarding import/export and deleting base template, please file it in separate bug.

Comment 13 sefi litmanovich 2016-04-20 07:39:45 UTC
Verifying this RFE based on the attached polarion test cases on ovirt-engine-4.0.0-0.0.master.20160405102116.git3819ab7.el7.centos.noarch.
Base functionality of the feature is working. A related bug was opened which isn't a blocker - https://bugzilla.redhat.com/show_bug.cgi?id=1328725.

Comment 15 errata-xmlrpc 2016-08-23 20:23:09 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.