Bug 964648 - Warn before deleting template which has derived VMS in export domain
Summary: Warn before deleting template which has derived VMS in export domain
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.2.0
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: 3.3.0
Assignee: Nobody's working on this, feel free to take it
QA Contact:
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-19 11:18 UTC by Dafna Ron
Modified: 2016-02-10 20:23 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-15 11:54:53 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
logs (1.50 MB, application/x-gzip)
2013-05-19 11:18 UTC, Dafna Ron
no flags Details

Description Dafna Ron 2013-05-19 11:18:11 UTC
Created attachment 750024 [details]
logs

Description of problem:

we can remove a template from the export domain without any warning even when the template has depended vms.
if the template was removed from setup as well, we will not be able to use the vm anymore.

Version-Release number of selected component (if applicable):

sf17

How reproducible:

100%

Steps to Reproduce:
1. export a vm created from template with its template to the export domain
2. remove the template
3.
 
Actual results:

we are able to remove the template with no warnings

Expected results:

we should have a warning since if the vm's template will also be removed in the setup the vm will no longer be usable.

Additional info: logs

Comment 1 Sergey Gotliv 2013-07-09 09:42:55 UTC
The existence of the template in the system has nothing to do with it.
We can also move the export domain between setups.
The feature is that you can export and import VMs and templates.
I can export the template, import into another setup and then remove the template.
I can export a VM without exporting the template to begin with so the VM is useless if I don't have a backup of it.

Comment 2 Dafna Ron 2013-07-09 11:15:47 UTC
(In reply to Sergey Gotliv from comment #1)
> The existence of the template in the system has nothing to do with it.
> We can also move the export domain between setups.
> The feature is that you can export and import VMs and templates.
> I can export the template, import into another setup and then remove the
> template.
> I can export a VM without exporting the template to begin with so the VM is
> useless if I don't have a backup of it.

the issue here is that when we remove the template from the export domain, the user should know that if it no longer exists in any setup the vm's linked to it will be useless. 
i don't see comment 1 as a reason for closed wontfix. 
reopening.

Comment 3 Ayal Baron 2013-07-15 11:54:53 UTC
(In reply to Dafna Ron from comment #2)
> (In reply to Sergey Gotliv from comment #1)
> > The existence of the template in the system has nothing to do with it.
> > We can also move the export domain between setups.
> > The feature is that you can export and import VMs and templates.
> > I can export the template, import into another setup and then remove the
> > template.
> > I can export a VM without exporting the template to begin with so the VM is
> > useless if I don't have a backup of it.
> 
> the issue here is that when we remove the template from the export domain,
> the user should know that if it no longer exists in any setup the vm's
> linked to it will be useless.

Yes, you explained it well to begin with and as mentioned above, you can export a VM without its template (without warning and none will be added there either) and then delete the template from the storage domain.
If you don't have that template anywhere else then your exported VM is useless in exactly the same way.

The simple fact is that it is totally valid by design to have incomplete VMs on the template domain.  That is the feature since we treat the export domain as a transfer station, not as a container of entire VMs


> i don't see comment 1 as a reason for closed wontfix. 
> reopening.


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