Red Hat Bugzilla – Bug 1194989
[RFE] Provide option to remove / replace base template while template sub-version exists
Last modified: 2016-08-23 16:23:09 EDT
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 . Regards, Jaison R
This bug did not make it in time for 3.6 release, moving out
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
*** Bug 1209892 has been marked as a duplicate of this bug. ***
*** Bug 1321078 has been marked as a duplicate of this bug. ***
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?
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.
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
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.
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.
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. https://rhn.redhat.com/errata/RHEA-2016-1743.html