[node-devel] Versioning of oVirt Node

[Alon Bar-Lev]

----- Original Message -----
> From: "Fabian Deutsch" <fabiand at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>, "Douglas Landgraf" <dlandgra at redhat.com>
> Sent: Monday, March 31, 2014 10:45:15 AM
> Subject: Re: [node-devel] Versioning of oVirt Node
> 
> Am Sonntag, den 30.03.2014, 04:57 -0400 schrieb Alon Bar-Lev:
> > 
> > ----- Original Message -----
> > > From: "Fabian Deutsch" <fabiand at redhat.com>
> > > To: arch at ovirt.org, "node-devel" <node-devel at ovirt.org>
> > > Cc: "Douglas Landgraf" <dlandgra at redhat.com>
> > > Sent: Friday, March 28, 2014 2:37:05 PM
> > > Subject: [node-devel] Versioning of oVirt Node
> > > 
> > > Hey,
> > > 
> > > currently [0] - or since the split into base image and layered image -
> > > the versioning of Node hasn't been really resolved.
> > > 
> > > I'd like to change the versioning of Node with the goal to make it
> > > directly obvious what oVirt version a Node is targeting.
> > > 
> > > Before I continue let me clarify that this is primarily about the
> > > versioning of the Node ISO.
> > > The versioning of the wrapper-rpm can possibly follow the naming of the
> > > ISO, as long as we make yum happy.
> > > Also this is not about the ovirt-node (pkg) versioning, only about the
> > > iso image.
> > > 
> > > Currently the ISO naming is as follows:
> > > 
> > >   ovirt-node-iso-<node-version>-<number>.<number>.<build-date>.\
> > >   vdsm<ovirt-target-version>.<dist>.iso
> > > 
> > > (i.e. ovirt-node-iso-3.0.4-1.0.201401291204.vdsm34.el6.iso)
> > > 
> > > The main pain point of this is IMO the vdsm34 snippet - because it
> > > breaks the whol envr and is currently just added after the edit-node
> > > pass.
> > > 
> > > I'm proposing the following scheme:
> > > 
> > >   ovirt-node-iso-<ovirt-target-version>-<build-date>.<number>.<dist>.iso
> > > 
> > > (i.e. ovirt-node-iso-3.4.0-20140328.1.el6.iso)
> > > 
> > > This should make it obvious to the user what ISO to use.
> > > 
> > > 
> > > Now about the rpm scheme. We can not change this as long as the Engine
> > > logic has not been updated to use the proposed metadata file:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1081969 (Node)
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1081970
> > > 
> > > Once these two bugs have been addressed we can also change the rpm
> > > naming.
> > > In general I'd like to follow the iso naming, thus:
> > > 
> > > ovirt-node-iso-<ovirt-target-version>-<build-date>.<number>.<dist>.rpm
> > 
> > 
> > I think that we should have upstream version for ovirt node as any other
> > upstream version we have.
> 
> Yeah, after sleeping a bit about this, I also believe that we can be
> more "conservative" when it comes to the rpm naming.
> 
> That means I could imagine going with the plain NVR …
> 
> > I also do not like dates embed within release as it will make our lives
> > difficult when we have proper bug tracking system in place.
> 
> … including without the build date, and only a propper (increasing)
> release verison.
> 
> > I am unsure what 'iso' means... I think it should be removed or converted
> > to subpackage.
> 
> The iso means that this package carries the ISO which can be deploayed
> by Engine.
> 
> ovirt-node - Package with the recipe/kickstart and actual codebase
> ovirt-node-iso - Wrapper for the ISO containing ovirt-node
> 
> I do not favor of making ovirt-node-iso a subpackage of ovirt-node.
> Because ovirt-node is actually contained in ovirt-node-iso.

ok, although the fact that it carries iso is not significant... as the binary (built) representation of node is iso...
but not that important :)

> 
> > Should we also consider parallel versions of different distributions(?)
> > (fc19, fc20).
> 
> In general I favor of having only one stable Node per distribution. Thus
> one for Fedora, and one for CentOS.
> 
> Besides that, we could investigate how yum is handling different dist
> tags on packages in the same repo.
> I.e.:
> node-3.0-0.fc19.rpm
> node-3.0-0.el6.rpm
> In the same repo.

no... it should be:

node-fc19-3.0-0.fc19.rpm
node-centos-3.0-0.fc19.rpm
node-fc19-3.0-0.el6.rpm
node-centos-3.0-0.el6.rpm

As there is no reason why I would not like centos hosts for my fedora engine :)

And there is no reason why we should not allow keeping these available side-by-side.


> If the el6 variant is installed on the Engine side, does yum
> automatically update to the 3.1 el6 variant when it comes out? Or does
> yum ignore the different dist-tags?
> 
> > Pre-release:
> > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm
> 
> Could you please give an example for this.

You can see lots of examples at other projects[1]

[1] http://resources.ovirt.org/pub/ovirt-snapshot/rpm/fc19/noarch/

> And - as noted above - I could live with dropping the date for the
> wrapper-rpms - tho it is still handy to have them.

Why is it handy, what is it serve?

> 
> > Released:
> > ovirt-node-iso-3.4.z-1.dist.rpm
> 
> would you replase z in that string above?

Each stable release/fix release you issue z is incremented async of any other package.

> 
> > Please note that the downstream component is eliminated in upstream,
> 
> Could you please exaplain this a bit more.

You wrote:

> > >   ovirt-node-iso-<ovirt-target-version>-<build-date>.<number>.<dist>.iso

This means that you have no upstream version for your own use... ovirt-target-version is of ovirt, but what is the version of the node?

I hope I answered your question.

> 
> > what important in upstream is the source tarball....
> > ovirt-ndoe-iso-3.4.z.tar.gz
> 
> Thanks for that lengthy input!
> 
> - fabian
>