Description of problem: Currently there is no central source of information to find out what version RHEV or RHEL is used by a RHEV-H build. To address this problem we should introduce a metadata file which includes - in a condensed form - relevant informations about the targeted RHEV and RHEL versions of a RHEV-H build. The metadata file should be delivered in the rpm (and not in the iso). The naming should follow the iso naming, ie: <isoname>.metadata The file can basically be an extended version of the /etc/default/version file within the iso. Which is extracted when the rpm is build. This has the benefit that the "outer" (rpm) file will be equal to the "inner" (within iso) file.
The already existing "version" file (in the rpm) does not contain enough informations. There also needs to be a bug to track the necessary changes on the RHEV-M side.
Fabian, for completeness please specify here the expected meta file contents.
In addition to the current contents we should add: ISONAME To be flexible on iso name changes within the rpm, we can use this indirection to tell RHEV-M about the iso to use, currently: rhevh-6.5-20140303.0.el6.iso (or so) PLATFORM_VERSION Major and Minor of the platform, e.g.: 6.5 We could consider to also include the update: 6.5.3 PLATFORM_RELEASE - and/or - BUILD_DATE Release part of the build, aka build date plus number, e.g.: 20140303.0 The reason for possibly calling it BUILD_DATE is to make the semantics explicit. LAYERED_VERSION - or - OVIRT_VERSION Major and Minor of the layered product, e.g.: 3.2 We could consider to also include the update: 3.2.6 This should give RHEV-M enough informations to suggest sane upgrade paths based on either platform and/or LP versions. By using PLATFORM_RELEASE or BUILD_DATE RHEV-M can even be made aware of new updates for old versions (e.g. 3.2.6) Douglas, do you think these informations are enough?
(In reply to Fabian Deutsch from comment #3) > In addition to the current contents we should add: > > ISONAME > To be flexible on iso name changes within the rpm, > we can use this indirection to tell RHEV-M about the iso to use, currently: > rhevh-6.5-20140303.0.el6.iso (or so) > > PLATFORM_VERSION > Major and Minor of the platform, e.g.: 6.5 > We could consider to also include the update: 6.5.3 > > PLATFORM_RELEASE - and/or - BUILD_DATE > Release part of the build, aka build date plus number, e.g.: 20140303.0 > The reason for possibly calling it BUILD_DATE is to make the semantics > explicit. > > LAYERED_VERSION - or - OVIRT_VERSION > Major and Minor of the layered product, e.g.: 3.2 > We could consider to also include the update: 3.2.6 > > This should give RHEV-M enough informations to suggest sane upgrade paths > based on either platform and/or LP versions. > > By using PLATFORM_RELEASE or BUILD_DATE RHEV-M can even be made aware of new > updates for old versions (e.g. 3.2.6) > > Douglas, do you think these informations are enough? Removing needinfo on me since there is a discussing going on about it.
As mentioned in bug 1081969, all informations are already available, just spread in two different files.