Description of problem: Currently there is no central source of information to find out what version oVirt/vdsm or Fedora/CentOS is used by a Node build. To address this problem we should introduce a metadata file which includes - in a condensed form - relevant informations about the targeted oVirt/vdsm and Fedora/CentOS versions of a Node 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.
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 Engine about the iso to use. PLATFORM_VERSION Major and Minor of the platform (Fedora/centos), e.g.: 19 We could consider to also include the update (centos): 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 oVirt 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?
We should probably also have a field which keeps the platform aka keeping the dist tag: PLATFORM_DIST The dist tag of the platform, e.g: fc19, fc20, el6
While this suggestion looks detailed I'm trying to understand how we are going to solve the following situations: - change in the metadata file format (happened in the past ... and caused us to move to this method we use today). - having the engine work with both versions in the same place. In addition while there are many details in the metadata file and some might be confusing, and I don't see the engine/user use so much information to decide to which version he can upgrade to: For example: - ISONAME - it looks flexible to enable iso name change, so let's say that the ISO name is changed, how should the engine scan of the directory look like. - PLATFORM_VERSION - Does the user/engine really need to know that - doesn't it miss the point of ovirt-node (be independent and generic ) LAYERED_VERSION - this should be the only relevant information required SO I think it would be better to move to a directory structure in which we'll have the LAYERED_VERSION as directory (or symbolic link) this way we make sure the format does not change, this is a part of the build process (should happen automatically), and we can handle past versioning in more or less the same way on the engine side.
(In reply to Barak from comment #3) > While this suggestion looks detailed I'm trying to understand how we are > going to solve the following situations: > > - change in the metadata file format (happened in the past ... and caused us > to move to this method we use today). We can add a field VERSION to track the version of the field. > - having the engine work with both versions in the same place. We could target this disruptive change for 4.0 where we don't need to be backwards compatible. Otherwise we need to loook how to support the old way. > In addition while there are many details in the metadata file and some might > be confusing, and I don't see the engine/user use so much information to > decide to which version he can upgrade to: Let me add before - The metadata file is not directly intended for the user, it is intended to deliver detailed informations about the ISO image. > For example: > - ISONAME - it looks flexible to enable iso name change, so let's say that > the > ISO name is changed, how should the engine scan of the directory look like. The idea behind the ISONAME field is that Engine determins the iso to be pushed to a Node by looking at this field, instead of scanning the directory for *.iso files. > - PLATFORM_VERSION - Does the user/engine really need to know that - doesn't > it miss the point of ovirt-node (be independent and generic ) Yes and no. I agree that the Node should be generic and should be a black box. But the recent history has shown that there are sometimes cases where you need the informations to workaround problems with a buggy Node. Also - This information could be used to ship pre-release Node's which are based on a newer platform. A general thought - IMO we will always base our Node on some distro. Thus we will always be based on some platform. And thus we should keep this information. Assuming that we ship our completely own ISO based on our very own package set and completely self build is unlikely - IMO. > LAYERED_VERSION - this should be the only relevant information required > > > SO I think it would be better to move to a directory structure in which > we'll have the LAYERED_VERSION as directory (or symbolic link) this way we > make sure the format does not change, this is a part of the build process > (should happen automatically), and we can handle past versioning in more or > less the same way on the engine side. If all the problems we had in the past would be all we ever meet I'd might have agreed :) I just see that problems come and go. To be able to address different problems in future, I'd like to keep more informations then we currently need. Simply relying on directories might help with the current situation, but might not give us to much flexibility when we run into trouble - in future. Let me note that some informations are redundant to the nvr of the rpm name. But - the redundancy is good to make Engine independent of the rpm naming, basically independent of the delivery format.
(In reply to Fabian Deutsch from comment #4) > (In reply to Barak from comment #3) > > While this suggestion looks detailed I'm trying to understand how we are > > going to solve the following situations: > > > > - change in the metadata file format (happened in the past ... and caused us > > to move to this method we use today). > > We can add a field VERSION to track the version of the field. than you will always have backwards compatibility issues with older verstions of engine, meaning old engines that need to work with newer and different versions of metadata. > > > - having the engine work with both versions in the same place. > > We could target this disruptive change for 4.0 where we don't need to be > backwards compatible. > Otherwise we need to loook how to support the old way. It is still not clear whether 4.0 is a clean start or could be upgraded from latest 3.X (e.g. RHEL 6.X should enable upgrade to RHEL 7) > > > In addition while there are many details in the metadata file and some might > > be confusing, and I don't see the engine/user use so much information to > > decide to which version he can upgrade to: > > Let me add before - The metadata file is not directly intended for the user, > it is intended to deliver detailed informations about the ISO image. > > > For example: > > - ISONAME - it looks flexible to enable iso name change, so let's say that > > the > > ISO name is changed, how should the engine scan of the directory look like. > > The idea behind the ISONAME field is that Engine determins the iso to be > pushed to a Node by looking at this field, instead of scanning the directory > for *.iso files. It still needs to scan for metadata files in the same dir so you reach the same problem > > > - PLATFORM_VERSION - Does the user/engine really need to know that - doesn't > > it miss the point of ovirt-node (be independent and generic ) > > Yes and no. I agree that the Node should be generic and should be a black > box. But the recent history has shown that there are sometimes cases where > you need the informations to workaround problems with a buggy Node. > If the engine does not have a specific logic to handle this information than this information is redundant for this use case. > Also - This information could be used to ship pre-release Node's which are > based on a newer platform. see above > > A general thought - IMO we will always base our Node on some distro. Thus we > will always be based on some platform. And thus we should keep this > information. > Assuming that we ship our completely own ISO based on our very own package > set and completely self build is unlikely - IMO. > > > LAYERED_VERSION - this should be the only relevant information required > > > > > > SO I think it would be better to move to a directory structure in which > > we'll have the LAYERED_VERSION as directory (or symbolic link) this way we > > make sure the format does not change, this is a part of the build process > > (should happen automatically), and we can handle past versioning in more or > > less the same way on the engine side. > > If all the problems we had in the past would be all we ever meet I'd might > have agreed :) > I just see that problems come and go. To be able to address different > problems in future, I'd like to keep more informations then we currently > need. > > Simply relying on directories might help with the current situation, but > might not give us to much flexibility when we run into trouble - in future. Can you please explain what kind of problems you are thinking about? Again I don't believe in solving unknown problems. > > > Let me note that some informations are redundant to the nvr of the rpm name. > But - the redundancy is good to make Engine independent of the rpm naming, > basically independent of the delivery format. I find it hard to believe that we'll ever add iso selection logic based on anything else than LAYERED_VERSION.
Yesterday there was a small meeting on this topic. Basically it seems that there is already enough informations provided by the oVirt Node rpm to let Engine make decisions, and we probably don't need a new metadata file. For now I'm lowering the priority, once we confirmed that the available informations are enough, we can close this. For the record: The existing metadata files are version.txt and vdsm-compatibility.txt
According to comment 6 all required informations are already available in existing files.