create workflow strategy for users' modified default templates

[mfc]

A user will install additional packages to a default template. This creates problems when trying to restore a modified default template to a new system, where that template will already exist.

Some potential options:

1. automatically create personal copies all templates on installations, have those be the templates used (so instead of fedora-21, my-fedora-21 is default). would eat up a lot of extra space.
2. when restoring templates/VMs and two different templates/VMs conflict with the same name, offer to modify the name of the template attempting to be restored

I think the second option makes the most sense. There may be other strategies regarding this.

[marmarek]

There is a chain of problems, I think rooted in the fact of using rpm for template distribution:

1. You need some template to restore a backup in some cases (UsbVM, NetVM - in case of NAS etc)
2. So, you need to install that template somehow - the only option is installation ISO (for the first template)
3. When the template is installed as RPM package, that package can be later removed. And if you rename the template, removing the RPM will fail (because files will be moved); if some other template was placed there instead, that template would be removed (#839)
4. The above is exactly the reason why manual rename or remove of rpm-installed template is blocked. This means that user can't easily restore modified default template from a backup.
5. Because of above, it is recommended (currently) to do modifications in clone of default template. This is the only reason. Other reason would be having an rpm update overriding user changes, but rpm upgrades of template packages are blocked exactly for this reason.

So, if we could solve #839 in some different way, this recommendation could be lifted. Also having #869 (exactly your second point) would improve/solve the problem. And yes - I think the current recommendation is a problem, not a solution. Needs to be fixed.

If you think #869 would be enough, lets close this one as a duplicate.

[marmarek]

There is a chain of problems, I think rooted in the fact of using rpm for template distribution:

1. You need some template to restore a backup in some cases (UsbVM, NetVM - in case of NAS etc)
2. So, you need to install that template somehow - the only option is installation ISO (for the first template)
3. When the template is installed as RPM package, that package can be later removed. And if you rename the template, removing the RPM will fail (because files will be moved); if some other template was placed there instead, that template would be removed (#839)
4. The above is exactly the reason why manual rename or remove of rpm-installed template is blocked. This means that user can't easily restore modified default template from a backup.
5. Because of above, it is recommended (currently) to do modifications in clone of default template. This is the only reason. Other reason would be having an rpm update overriding user changes, but rpm upgrades of template packages are blocked exactly for this reason.

So, if we could solve #839 in some different way, this recommendation could be lifted. Also having #869 (exactly your second point) would improve/solve the problem. And yes - I think the current recommendation is a problem, not a solution. Needs to be fixed.

If you think #869 would be enough, lets close this one as a duplicate.

[andrewdavidwong]

Is this a possible duplicate of #1403? Even if not, it definitely seems closely related...

[andrewdavidwong]

Is this a possible duplicate of #1403? Even if not, it definitely seems closely related...

[mfc]

yeah, for now I think #869 would be enough, though as you note it doesn't tackle the underlying issues (which #1403 also highlights).

[mfc]

yeah, for now I think #869 would be enough, though as you note it doesn't tackle the underlying issues (which #1403 also highlights).

[marmarek]

Another idea about a solution for #839 - instead of blocking some template changes (namely: rename, delete) fearing interference with package manager, maybe we should proceed in totally opposite way: require user to first delete such (template) VM, and refuse to remove the package if TemplateVM isn't deleted manually beforehand?
This way we will mitigate a problem of removing wrong template while removing package and also leave some more flexibility in template management.

[marmarek]

Another idea about a solution for #839 - instead of blocking some template changes (namely: rename, delete) fearing interference with package manager, maybe we should proceed in totally opposite way: require user to first delete such (template) VM, and refuse to remove the package if TemplateVM isn't deleted manually beforehand?
This way we will mitigate a problem of removing wrong template while removing package and also leave some more flexibility in template management.