[node-devel] Versioning of oVirt Node

Mon Mar 31 07:48:13 UTC 2014

Am Sonntag, den 30.03.2014, 08:45 -0400 schrieb Barak Azulay:
> 
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > To: "Barak Azulay" <bazulay at redhat.com>
> > Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel"
> > <node-devel at ovirt.org>
> > Sent: Sunday, March 30, 2014 12:53:32 PM
> > Subject: Re: [node-devel] Versioning of oVirt Node
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Barak Azulay" <bazulay at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: "Fabian Deutsch" <fabiand at redhat.com>, arch at ovirt.org, "Douglas
> > > Landgraf" <dlandgra at redhat.com>, "node-devel"
> > > <node-devel at ovirt.org>
> > > Sent: Sunday, March 30, 2014 12:51:05 PM
> > > Subject: Re: [node-devel] Versioning of oVirt Node
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > > From: "Alon Bar-Lev" <alonbl at redhat.com>
> > > > To: "Fabian Deutsch" <fabiand at redhat.com>
> > > > Cc: arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>,
> > > > "node-devel"
> > > > <node-devel at ovirt.org>
> > > > Sent: Sunday, March 30, 2014 11:57:09 AM
> > > > Subject: Re: [node-devel] Versioning of oVirt Node
> > > > 
> > > > 
> > > > 
> > > > ----- 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.
> > > > 
> > > > 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.
> > > > 
> > > > I am unsure what 'iso' means... I think it should be removed or converted
> > > > to
> > > > subpackage.
> > > > 
> > > > Should we also consider parallel versions of different distributions(?)
> > > > (fc19, fc20).
> > > 
> > > Doesn't this miss the entire node purpose ? a user should not care what
> > > platform was used to build the node.
> > 
> > If we keep in parallel different distributions per single version of ovirt,
> > we should somehow mark it in the binary output.
> > 
> > For example we have experimental fedora-21 image based on
> > ovirt-node-iso-3.4.2, while release is based on fedora-19.
> 
> The purpose of ovirt-node is to be distribution agnostic (see esx server).
> If we have experimental image than it should be marked as such - not that it is based on f-21.
> The developers should know exactly what distro/version it was built from, I don't think that users care.

Technically the wrapper-rpm is noarch. Because the contained iso is
independent of the host-architecture.

Besides that I'd reflect the OS in the rpm name.
And as my last comment - the classification if an ISO/rpm is stable or
not is done by placing the rpm in the correct (stable or beta) repo.

- fabian

> Barak 
> 
>  
> 
> > 
> > > 
> > > 
> > > 
> > > > 
> > > > Pre-release:
> > > > ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm
> > > > 
> > > > Released:
> > > > ovirt-node-iso-3.4.z-1.dist.rpm
> > > > 
> > > > Please note that the downstream component is eliminated in upstream, what
> > > > important in upstream is the source tarball....
> > > > 
> > > > ovirt-ndoe-iso-3.4.z.tar.gz
> > > > 
> > > > Regards,
> > > > Alon
> > > > _______________________________________________
> > > > Arch mailing list
> > > > Arch at ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/arch
> > > > 
> > > > 
> > > > 
> > > 
> > 

-------------- 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/7aa61a1d/attachment.sig>