Versioning of oVirt Node

Discussion:

Fabian Deutsch

2014-03-28 11:37:05 UTC

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.e. ovirt-node-iso-3.4.0-20140328.1.el6.rpm)

A couple of examples:
# Newer build, same day
$ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20140328.2
0:3.4.0-20140328.1 < 0:3.4.0-20140328.2

# Same build
$ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20140328.1
0:3.4.0-20140328.1 == 0:3.4.0-20140328.1

# Older and newer build, same day
$ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20140328.0
0:3.4.0-20140328.1 > 0:3.4.0-20140328.0

# Same ver, one year later
$ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20150328.1
0:3.4.0-20140328.1 < 0:3.4.0-20150328.1

# New ver
$ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.5.0-20140328.1
0:3.4.0-20140328.1 < 0:3.5.0-20140328.1

# Older ver, newer build date
$ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.3.0-20150328.1
0:3.4.0-20140328.1 > 0:3.3.0-20150328.1
(Would not get installed by yum automatically)

In general the names of the iso and rpm should not be relevant for
Engine to decide about updates. The metadata file of the rpm will be
used for that.

Finally, are there objections to of changing the ISO versioning scheme
now? Or does someone see problems with it?

Greetings
fabian

---
[0] http://plain.resources.ovirt.org/releases/3.4/iso/
-------------- 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/arch/attachments/20140328/69717eec/attachment.sig>

Fabian Deutsch

2014-03-28 11:39:38 UTC

Permalink

Post by Fabian Deutsch
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.

I am also suggesting that the base image should continue to use the
ovirt-node (pkg) versions, thus:

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

(i.e. ovirt-node-base-iso-3.0.4-20140328.1.el6.iso)

The base iso is used to derive the Node-for-Engine iso.

Greetings
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/arch/attachments/20140328/4befa2e5/attachment.sig>

Doron Fediuck

2014-03-30 06:24:36 UTC

Permalink

----- Original Message -----

From: "Fabian Deutsch" <fabiand at redhat.com>
To: arch at ovirt.org
Cc: "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel" <node-devel at ovirt.org>
Sent: Friday, March 28, 2014 2:39:38 PM
Subject: Re: [node-devel] Versioning of oVirt Node

I am also suggesting that the base image should continue to use the
ovirt-node-base-iso-<ovirt-node-version>-<build-date>.<number>.<dist>.iso
(i.e. ovirt-node-base-iso-3.0.4-20140328.1.el6.iso)
The base iso is used to derive the Node-for-Engine iso.
Greetings
fabian

Sounds reasonable to me.

Barak Azulay

2014-03-30 08:46:11 UTC

Permalink

----- 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.
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.
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
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.
ovirt-node-iso-<ovirt-target-version>-<build-date>.<number>.<dist>.rpm
(i.e. ovirt-node-iso-3.4.0-20140328.1.el6.rpm)
# Newer build, same day
$ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20140328.2
0:3.4.0-20140328.1 < 0:3.4.0-20140328.2
# Same build
$ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20140328.1
0:3.4.0-20140328.1 == 0:3.4.0-20140328.1
# Older and newer build, same day
$ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20140328.0
0:3.4.0-20140328.1 > 0:3.4.0-20140328.0
# Same ver, one year later
$ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.4.0-20150328.1
0:3.4.0-20140328.1 < 0:3.4.0-20150328.1
# New ver
$ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.5.0-20140328.1
0:3.4.0-20140328.1 < 0:3.5.0-20140328.1
# Older ver, newer build date
$ rpmdev-vercmp 0:3.4.0-20140328.1 0:3.3.0-20150328.1
0:3.4.0-20140328.1 > 0:3.3.0-20150328.1
(Would not get installed by yum automatically)
In general the names of the iso and rpm should not be relevant for
Engine to decide about updates. The metadata file of the rpm will be
used for that.
Finally, are there objections to of changing the ISO versioning scheme
now? Or does someone see problems with it?

I assume that this new schema is handling also the frist upgrade from the old name schema.

Barak

Greetings
fabian
---
[0] http://plain.resources.ovirt.org/releases/3.4/iso/
_______________________________________________
node-devel mailing list
node-devel at ovirt.org
http://lists.ovirt.org/mailman/listinfo/node-devel

Fabian Deutsch

2014-03-31 06:39:55 UTC

Permalink

Post by Barak Azulay
I assume that this new schema is handling also the frist upgrade from the old name schema.

Hey Barak,

could you explain what the first upgrade to the old schema name was for
you?

- 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/arch/attachments/20140331/89fd7de4/attachment.sig>

Barak Azulay

2014-03-31 09:08:48 UTC

Permalink

----- Original Message -----

From: "Fabian Deutsch" <fabiand at redhat.com>
To: "Barak Azulay" <bazulay 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 9:39:55 AM
Subject: Re: [node-devel] Versioning of oVirt Node

Post by Barak Azulay
I assume that this new schema is handling also the frist upgrade from
the old name schema.

Hey Barak,
could you explain what the first upgrade to the old schema name was for
you?

There are 2 scenarios that needs to be considered:
1 older engine with new rhevh (with new name schema)
* customer with rhev 3.4 tries to upgrade a 3.4 cluster level rhevh to the latest rhevh (with new name schema ... 3.4 cluster level)

2 newer engine supporting older clustrers:
* assume you have 3.4 engine out with several ISOs located in the same dir,
Than there is an upgrade to 3.5 where the name schema changes (and in the same dir you have old name schema and new name schema),
Than you want to upgrade a 3.4 cluster level rhevh to the latest rhevh (with new name schema ... 3.4 cluster level)

In both cases the UI should suggest the best fit for upgrade,
While for #2 we can add some logic to the engine to handle both cases (ugly and problematic),
For #1 above there is very little we can do.

- fabian

Fabian Deutsch

2014-04-03 09:04:07 UTC

Permalink

Post by Doron Fediuck
----- Original Message -----

Post by Barak Azulay
I assume that this new schema is handling also the frist upgrade from
the old name schema.

Hey Barak,
could you explain what the first upgrade to the old schema name was for
you?

1 older engine with new rhevh (with new name schema)
* customer with rhev 3.4 tries to upgrade a 3.4 cluster level rhevh to the latest rhevh (with new name schema ... 3.4 cluster level)

Mh.
What about picking up Alon's (IIRC) suggestion to use subdirs.
The "old" names would reside in the path where they are now.
And new isos are placed in a subdirectory, where the name of the
subdirectory is the targeted version (e.g. 3.4/ would contain Node's for
3.4)
That way we don't collide with the old scheme.
Newer isos could be brought to old Engines by doing some fancy
symlinking.

Post by Doron Fediuck
* assume you have 3.4 engine out with several ISOs located in the same dir,
Than there is an upgrade to 3.5 where the name schema changes (and in the same dir you have old name schema and new name schema),
Than you want to upgrade a 3.4 cluster level rhevh to the latest rhevh (with new name schema ... 3.4 cluster level)

Maybe this is also solvable by using subdirs as described above.

But maybe I'm not getting you right.

- fabian

Post by Doron Fediuck
In both cases the UI should suggest the best fit for upgrade,
While for #2 we can add some logic to the engine to handle both cases (ugly and problematic),
For #1 above there is very little we can do.

-------------- 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/arch/attachments/20140403/0952f2df/attachment.sig>

Alon Bar-Lev

2014-03-30 08:57:09 UTC

Permalink

----- Original Message -----

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).

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

Barak Azulay

2014-03-30 09:51:05 UTC

Permalink

----- 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 -----

Doesn't this miss the entire node purpose ? a user should not care what platform was used to build the node.

ovirt-node-iso-3.4.0-0.$(sequence).$(branch).$(date).dist.rpm
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

Alon Bar-Lev

2014-03-30 09:53:32 UTC

Permalink

----- 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 -----

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.

Barak Azulay

2014-03-30 12:45:56 UTC

Permalink

----- 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 -----

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.

Barak

Alon Bar-Lev

2014-03-30 12:49:13 UTC

Permalink

----- 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 3:45:56 PM
Subject: Re: [node-devel] Versioning of oVirt Node
----- 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 -----

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.

I am unsure users will not care if we can offer options for multiple images that works with the same ovirt milestone.
But this is not that important at this point.

Barak

Doron Fediuck

2014-03-31 06:55:53 UTC

Permalink

----- Original Message -----

From: "Alon Bar-Lev" <alonbl at redhat.com>
To: "Barak Azulay" <bazulay 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 3:49:13 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 3:45:56 PM
Subject: Re: [node-devel] Versioning of oVirt Node
----- 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 -----

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.

I am unsure users will not care if we can offer options for multiple images
that works with the same ovirt milestone.
But this is not that important at this point.

+1.
I had a long conversation with a user who insists on Debian based hosts.
I tried to explain him he should consider it as black box / appliance but
he wouldn't want to hear about it.

Barak

_______________________________________________
Arch mailing list
Arch at ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch

Fabian Deutsch

2014-03-31 07:48:13 UTC

Permalink

Post by Doron Fediuck
----- 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 -----

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.

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

Post by Doron Fediuck
Barak

Fabian Deutsch

2014-03-31 07:46:01 UTC

Permalink

Post by Alon Bar-Lev

Post by Alon Bar-Lev
Should we also consider parallel versions of different

distributions(?)

Post by Alon Bar-Lev
(fc19, fc20).

Doesn't this miss the entire node purpose ? a user should not care
what platform was used to build the node.

As said elsewhere. For some users the base-os is important to know.

- 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/arch/attachments/20140331/062eb740/attachment.sig>

Barak Azulay

2014-03-31 09:16:38 UTC

Permalink

----- Original Message -----

From: "Fabian Deutsch" <fabiand at redhat.com>
To: "Barak Azulay" <bazulay at redhat.com>
Cc: arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel" <node-devel at ovirt.org>
Sent: Monday, March 31, 2014 10:46:01 AM
Subject: Re: [node-devel] Versioning of oVirt Node

Post by Alon Bar-Lev

Post by Alon Bar-Lev
Should we also consider parallel versions of different

distributions(?)

Post by Alon Bar-Lev
(fc19, fc20).

Doesn't this miss the entire node purpose ? a user should not care
what platform was used to build the node.

As said elsewhere. For some users the base-os is important to know.

Any idea why ?

The only thing I can think off is that we are probably doing something wrong.

- fabian
_______________________________________________
Arch mailing list
Arch at ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch

Fabian Deutsch

2014-03-31 09:41:43 UTC

Permalink

Post by Doron Fediuck
----- Original Message -----

Post by Alon Bar-Lev

Post by Alon Bar-Lev
Should we also consider parallel versions of different

distributions(?)

Post by Alon Bar-Lev
(fc19, fc20).

Doesn't this miss the entire node purpose ? a user should not care
what platform was used to build the node.

As said elsewhere. For some users the base-os is important to know.

Any idea why ?
The only thing I can think off is that we are probably doing something wrong.

Some people just want to use CentOS, others favor Fedora.

I believe partially it's just a personal preference.

OTOH it is surely the case that el6 is slower moving then Fedora, and
thus it is more stable. I'd also say that this is true for the el6 based
Node.

We keep the Fedora based Node around - or bring it back - to have a
platform to develop on.

- fabian

Post by Doron Fediuck

- fabian
_______________________________________________
Arch mailing list
Arch at ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch

Fabian Deutsch

2014-03-31 07:45:15 UTC

Permalink

Post by Doron Fediuck
----- Original Message -----

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 ?

Post by Doron Fediuck
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.

Post by Doron Fediuck
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.

Post by Doron Fediuck
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?

Post by Doron Fediuck
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.

Post by Doron Fediuck
ovirt-node-iso-3.4.z-1.dist.rpm

would you replase z in that string above?

Post by Doron Fediuck
Please note that the downstream component is eliminated in upstream,

Could you please exaplain this a bit more.

Post by Doron Fediuck
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/arch/attachments/20140331/b0aa57ed/attachment.sig>

Alon Bar-Lev

2014-03-31 08:52:39 UTC

Permalink

----- 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

Post by Doron Fediuck
----- Original Message -----

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 ?

Post by Doron Fediuck
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.

Post by Doron Fediuck
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 :)

Post by Doron Fediuck
Should we also consider parallel versions of different distributions(?) (fc19, fc20).

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?

Post by Doron Fediuck
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?

Post by Doron Fediuck
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.

Post by Doron Fediuck
Please note that the downstream component is eliminated in upstream,

Could you please exaplain this a bit more.

Post by Doron Fediuck

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.

Post by Doron Fediuck
what important in upstream is the source tarball....
ovirt-ndoe-iso-3.4.z.tar.gz

Thanks for that lengthy input!
- fabian

Barak Azulay

2014-03-31 09:20:59 UTC

Permalink

----- 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: Monday, March 31, 2014 11:52:39 AM
Subject: Re: [node-devel] Versioning of oVirt Node
----- 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

Post by Doron Fediuck
----- Original Message -----

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 ?

Post by Doron Fediuck
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.

Post by Doron Fediuck
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 :)

Post by Doron Fediuck
Should we also consider parallel versions of different distributions(?)
(fc19, fc20).

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.

The logic of selection the most appropriate upgrade suggest different.

Guys again if users need to know what distro ovirt-node is constructed from than it misses the entire point of the node

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?

Post by Doron Fediuck
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?

Post by Doron Fediuck
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.

Post by Doron Fediuck
Please note that the downstream component is eliminated in upstream,

Could you please exaplain this a bit more.

Post by Doron Fediuck

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.

Post by Doron Fediuck
what important in upstream is the source tarball....
ovirt-ndoe-iso-3.4.z.tar.gz

Thanks for that lengthy input!
- fabian

_______________________________________________
Arch mailing list
Arch at ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch

Alon Bar-Lev

2014-03-31 09:29:23 UTC

Permalink

----- 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: Monday, March 31, 2014 12:20:59 PM
Subject: Re: [node-devel] Versioning of oVirt Node

Post by Alon Bar-Lev
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.

The logic of selection the most appropriate upgrade suggest different.

This should be solved by provides statement.

Guys again if users need to know what distro ovirt-node is constructed from
than it misses the entire point of the node

If you base your implementation on specific distribution, then I do mind which, as I want to modify, build and use customized versions, and has no knowledge how to do that in red hat based os.

As long as fedora instability and methods or centos/rhel old component enforcements are used, why not allowing debian users to feel comfortable as well, allowing them to pull this into their direction? Maybe at the end stable debian is the right way to go?

Had you created your tiny distribution based on busybox, libvirt, vdsm etc... cross compile all from sources, then you would have been right, as it is our own distribution that fully controlled by the ovirt community.

Alon

Barak Azulay

2014-03-31 10:19:52 UTC

Permalink

----- 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: Monday, March 31, 2014 12:29:23 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: Monday, March 31, 2014 12:20:59 PM
Subject: Re: [node-devel] Versioning of oVirt Node

Post by Alon Bar-Lev
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.

The logic of selection the most appropriate upgrade suggest different.

This should be solved by provides statement.

Guys again if users need to know what distro ovirt-node is constructed from
than it misses the entire point of the node

If you base your implementation on specific distribution, then I do mind
which, as I want to modify, build and use customized versions, and has no
knowledge how to do that in red hat based os.
As long as fedora instability and methods or centos/rhel old component
enforcements are used, why not allowing debian users to feel comfortable as
well, allowing them to pull this into their direction? Maybe at the end
stable debian is the right way to go?
Had you created your tiny distribution based on busybox, libvirt, vdsm etc...
cross compile all from sources, then you would have been right, as it is our
own distribution that fully controlled by the ovirt community.

If a user need to customize the hypervisor he can use a regular OS of his choice configured and tailored to his needs (Fedora ..., CentOS ...Debian, Gentoo ...)
This is a valid use case and effort for the community.

While having a black box hypervisor, should be the exact fit to just run VMs in oVirt environment.
Why to handle specific OS configuration in a much more complex and less intuitive environment to manage ?

Guys I really think this entirely misses the black-box approach.

I don't mind moving to our own tiny distro as long as it's a single image to release and maintain

The effort of maintaining multiple ovirt-nodes based on distro and distro-version and ovirt-version creates an unmanageable test matrix that all the community might loose from

Alon

Fabian Deutsch

2014-03-31 11:21:57 UTC

Permalink

Post by Alon Bar-Lev

Post by Alon Bar-Lev
Had you created your tiny distribution based on busybox, libvirt,

vdsm etc...

Post by Alon Bar-Lev
cross compile all from sources, then you would have been right, as

it is our

Post by Alon Bar-Lev
own distribution that fully controlled by the ovirt community.

If a user need to customize the hypervisor he can use a regular OS of
his choice configured and tailored to his needs (Fedora ...,
CentOS ...Debian, Gentoo ...)
This is a valid use case and effort for the community.
While having a black box hypervisor, should be the exact fit to just
run VMs in oVirt environment.
Why to handle specific OS configuration in a much more complex and
less intuitive environment to manage ?
Guys I really think this entirely misses the black-box approach.
I don't mind moving to our own tiny distro as long as it's a single
image to release and maintain

Well, Node _is_ actually a tiny distro, just based on some package based
on some existing one.

Post by Alon Bar-Lev
The effort of maintaining multiple ovirt-nodes based on distro and
distro-version and ovirt-version creates an unmanageable test matrix
that all the community might loose from

I partially agree here.
From my POV the Fedora based Node is very useful for us to develop Node,
sooner or later the changes we've got in Fedora will land in CentOS,
thus devleoping on Fedora is a preparation for being able to deliver a
(stable) CentOS based Node.

So IMO we should continue to develop on Fedora, but we might want to
consider to keep to only deliver the CentOS based Node.
The Fedora based build could be seen as nightlies.

- 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/arch/attachments/20140331/bbecc2db/attachment.sig>

Alon Bar-Lev

2014-03-31 11:57:56 UTC

Permalink

----- Original Message -----

From: "Fabian Deutsch" <fabiand at redhat.com>
To: "Barak Azulay" <bazulay at redhat.com>
Cc: "Alon Bar-Lev" <alonbl at redhat.com>, arch at ovirt.org, "Douglas Landgraf" <dlandgra at redhat.com>, "node-devel"
<node-devel at ovirt.org>
Sent: Monday, March 31, 2014 2:21:57 PM
Subject: Re: [node-devel] Versioning of oVirt Node

Post by Alon Bar-Lev

Post by Alon Bar-Lev
Had you created your tiny distribution based on busybox, libvirt,

vdsm etc...

Post by Alon Bar-Lev
cross compile all from sources, then you would have been right, as

it is our

Post by Alon Bar-Lev
own distribution that fully controlled by the ovirt community.

If a user need to customize the hypervisor he can use a regular OS of
his choice configured and tailored to his needs (Fedora ...,
CentOS ...Debian, Gentoo ...)
This is a valid use case and effort for the community.
While having a black box hypervisor, should be the exact fit to just
run VMs in oVirt environment.
Why to handle specific OS configuration in a much more complex and
less intuitive environment to manage ?
Guys I really think this entirely misses the black-box approach.
I don't mind moving to our own tiny distro as long as it's a single
image to release and maintain

Well, Node _is_ actually a tiny distro, just based on some package based
on some existing one.

I do not think that it is tiny distro... but let's not get into this argument :)

Post by Alon Bar-Lev
The effort of maintaining multiple ovirt-nodes based on distro and
distro-version and ovirt-version creates an unmanageable test matrix
that all the community might loose from

If we consider single base distribution (aka blackbox which is not black at all...), and you agree that centos is a fit, I do not see any reason to invest resources in fedora.

- fabian

Fabian Deutsch

2014-03-31 12:34:19 UTC