Description of problem: It would be nice (and is related to bug ) that he-setup will detect pre-installed appliance images (i.e. in some predefined path, or using some config file) and will suggest to use one of them during installation.
This is basically an improvement for bug 1077850.
The pre installed appliance image could be installed on the system using yum or some other delivery mechanism
How should the detection work? Currently the names of the u/s and d/s rpms are ovirt-engine-appliance and rhevm-appliance respectively. The path in which the final ova will reside contains the name of the rpm: /usr/share/%{name}/….ova The question is: How does he-setup detect the available image(s)? - Does he-setup look in both directories? - Is more than one image allowed per directory? - Should both rpms should lay down the image in the same path (i.e. /usr/share/engine-appliance) Then only one path is used for d/s and u/s - Should the rpms but a small snippet/file somewhere in /etc/ to register the installed images with he-setup ?
It's not an issue to use different directory name from upstream to downstream. On my opinion /usr/share/%{name}/ looks good. If we are going to provide the OVA images via rpm, when you upgrade the rpm you should upgrade the correspondent ova removing the previous one. On my opinion no need to keep the old OVA in place since you can simply downgrade the rpm to choose it. A file entry in /etc/ with the filename and an sha1 sum could be a good idea for validating it.
(In reply to Simone Tiraboschi from comment #5) > It's not an issue to use different directory name from upstream to > downstream. > On my opinion /usr/share/%{name}/ looks good. Mh. I'm not convinced yet :) I see that it is initially easier to have separate dirs for the different images, because they align with the naming of the rpm that provides them. My main concern really is about he-setup to need to know more than one directory. > If we are going to provide the OVA images via rpm, when you upgrade the rpm > you should upgrade the correspondent ova removing the previous one. On my > opinion no need to keep the old OVA in place since you can simply downgrade > the rpm to choose it. Yes, we'll hadnle it like normal rpms. So only the last is kept. > A file entry in /etc/ with the filename and an sha1 sum could be a good idea > for validating it. If we have this file, then we could include the absolute path to the image in that checksum file. I.e.: Path for checksum files: /etc/hosted-engine-setup/engine-appliances.d/ Contents of a checksum file: $ cat ovirt-engine-appliances 1b856d2a14b3bf366e970170574e2960 /usr/share/ovirt-engine-appliance/….ova $ cat rhevm-appliances 289332a14bae3bf566e97670592e2957 /usr/share/rhevm-appliance/….ova
After the discussion on irc we agreed on the following: Both appliances (u/s and d/s) are expected to not be installed at the same time. Both appliances own the file /etc/ovirt-hosted-engine/10-appliance.conf This file has the following (example) contents: $ cat /etc/ovirt-hosted-engine/10-appliance.conf description=The oVirt Engine Appliance image (OVA) version=20150512.0-1 path=/usr/share/ovirt-engine-appliance/ovirt-engine-appliance-20150512.0-1.ova sha1sum=da39a3ee5e6b4b0d3255bfef95601890afd80709 The description is used during the he-setup, to let the user know what appliance is used. the path is pointing to the actual OVA. Both appliance OVAs will reside in /usr/share/ovirt-engine-appliance/ but have different names (derived from the package name [ovirt-engine-appliance vs rhevm-appliance]). The sha1sum can be used to verify the integrity of the image. The version can be used for informative purposes.
The first wrapper builds following the scheme in comment 7 are available now, please see the details in bug 1211933 comment 4.
*** Bug 1228147 has been marked as a duplicate of this bug. ***
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-0375.html