[node-devel] Versioning of oVirt Node

[Fabian Deutsch]

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.

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

> Released:
> ovirt-node-iso-3.4.z-1.dist.rpm

would you replase z in that string above?

> Please note that the downstream component is eliminated in upstream, 

Could you please exaplain this a bit more.

> what important in upstream is the source tarball....
> ovirt-ndoe-iso-3.4.z.tar.gz

Thanks for that lengthy input!

- fabian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ovirt.org/pipermail/node-devel/attachments/20140331/b0aa57ed/attachment.sig>