From fabiand at redhat.com  Thu Apr  3 09:04:07 2014
From: fabiand at redhat.com (Fabian Deutsch)
Date: Thu, 03 Apr 2014 11:04:07 +0200
Subject: [node-devel] Versioning of oVirt Node
In-Reply-To: <80562838.4387376.1396256928698.JavaMail.zimbra@redhat.com>
References: <1396006625.2943.43.camel@fdeutsch-laptop.local>
	<859671594.4143833.1396169171061.JavaMail.zimbra@redhat.com>
	<1396247995.3043.4.camel@fdeutsch-laptop.local>
	<80562838.4387376.1396256928698.JavaMail.zimbra@redhat.com>
Message-ID: <1396515847.3057.34.camel@fdeutsch-laptop.local>

Am Montag, den 31.03.2014, 05:08 -0400 schrieb Barak Azulay:
> 
> ----- 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
> > 
> > Am Sonntag, den 30.03.2014, 04:46 -0400 schrieb 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)

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.

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

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

But maybe I'm not getting you right.

- fabian

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

From fabiand at redhat.com  Thu Apr  3 09:09:47 2014
From: fabiand at redhat.com (Fabian Deutsch)
Date: Thu, 03 Apr 2014 11:09:47 +0200
Subject: [node-devel] Versioning of oVirt Node
In-Reply-To: <890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com>
References: <1396006625.2943.43.camel@fdeutsch-laptop.local>
	<1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com>
	<1396251915.3043.24.camel@fdeutsch-laptop.local>
	<890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com>
Message-ID: <1396516187.3057.38.camel@fdeutsch-laptop.local>

Am Montag, den 31.03.2014, 04:52 -0400 schrieb Alon Bar-Lev:
> > 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

I don't favor such a direction. If the user want's this he could deploy
the "alien" isos manually.

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

Thanks.

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

I was about to say t get have an idea about the build date, and having
an incrementing number.
But all this can either be achieved by looking at the iso contents or by
simple incrementing numbers aka (spec) release numbers.

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

Oh right. Well the "node" version can be retrieved by looking at the
version of the contained ovirt-node pkg. We don't need to expose it in
the name.

That's actually what I want to avoid - to expose the node version -
because this isn't helpful to th euser - even worse - it is confusing.

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

From alonbl at redhat.com  Thu Apr  3 09:41:23 2014
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 3 Apr 2014 05:41:23 -0400 (EDT)
Subject: [node-devel] Versioning of oVirt Node
In-Reply-To: <1396516187.3057.38.camel@fdeutsch-laptop.local>
References: <1396006625.2943.43.camel@fdeutsch-laptop.local>
	<1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com>
	<1396251915.3043.24.camel@fdeutsch-laptop.local>
	<890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com>
	<1396516187.3057.38.camel@fdeutsch-laptop.local>
Message-ID: <760216481.935128.1396518083947.JavaMail.zimbra@redhat.com>



----- 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: Thursday, April 3, 2014 12:09:47 PM
> Subject: Re: [node-devel] Versioning of oVirt Node
> 
> Am Montag, den 31.03.2014, 04:52 -0400 schrieb Alon Bar-Lev:
> > > 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
> 
> I don't favor such a direction. If the user want's this he could deploy
> the "alien" isos manually.

Why alien? I would like fedora engine and the most stable host I can get.
Or I would like to experiment with the next fedora on separate datacenter.
Nothing should be alien.

> 
> > 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/
> 
> Thanks.
> 
> > > 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?
> 
> I was about to say t get have an idea about the build date, and having
> an incrementing number.
> But all this can either be achieved by looking at the iso contents or by
> simple incrementing numbers aka (spec) release numbers.
> 
> > > 
> > > > 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?
> 
> Oh right. Well the "node" version can be retrieved by looking at the
> version of the contained ovirt-node pkg. We don't need to expose it in
> the name.
> 
> That's actually what I want to avoid - to expose the node version -
> because this isn't helpful to th euser - even worse - it is confusing.

On the contrary... the node version is the part that is important, this is the upstream version of the component, and should not be hidden.

> 
> Greetings!
> fabian
> 


From fabiand at redhat.com  Thu Apr  3 09:45:25 2014
From: fabiand at redhat.com (Fabian Deutsch)
Date: Thu, 03 Apr 2014 11:45:25 +0200
Subject: [node-devel] Versioning of oVirt Node
In-Reply-To: <760216481.935128.1396518083947.JavaMail.zimbra@redhat.com>
References: <1396006625.2943.43.camel@fdeutsch-laptop.local>
	<1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com>
	<1396251915.3043.24.camel@fdeutsch-laptop.local>
	<890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com>
	<1396516187.3057.38.camel@fdeutsch-laptop.local>
	<760216481.935128.1396518083947.JavaMail.zimbra@redhat.com>
Message-ID: <1396518325.3057.43.camel@fdeutsch-laptop.local>

Am Donnerstag, den 03.04.2014, 05:41 -0400 schrieb 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: Thursday, April 3, 2014 12:09:47 PM
> > Subject: Re: [node-devel] Versioning of oVirt Node
> > 
> > Am Montag, den 31.03.2014, 04:52 -0400 schrieb Alon Bar-Lev:
> > > > 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
> > 
> > I don't favor such a direction. If the user want's this he could deploy
> > the "alien" isos manually.
> 
> Why alien? I would like fedora engine and the most stable host I can get.
> Or I would like to experiment with the next fedora on separate datacenter.
> Nothing should be alien.
> 
> > 
> > > 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/
> > 
> > Thanks.
> > 
> > > > 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?
> > 
> > I was about to say t get have an idea about the build date, and having
> > an incrementing number.
> > But all this can either be achieved by looking at the iso contents or by
> > simple incrementing numbers aka (spec) release numbers.
> > 
> > > > 
> > > > > 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?
> > 
> > Oh right. Well the "node" version can be retrieved by looking at the
> > version of the contained ovirt-node pkg. We don't need to expose it in
> > the name.
> > 
> > That's actually what I want to avoid - to expose the node version -
> > because this isn't helpful to th euser - even worse - it is confusing.
> 
> On the contrary... the node version is the part that is important, this is the upstream version of the component, and should not be hidden.

We keep the version for the "real" component which is the ovirt-node
package.
Further more we could say that the ovirt-node-iso component is a
component on it's own with it's own version.
Because the ISO is squashing many packages I don't see a hard reason why
it should have the version of the ovirt-node package.
And my suggestion is to let the ovirt-node-iso component follow the
overall/project version.

For us "No(o)dlers"" it would be interesting to see the ovirt-node
version.
For "vdsmlers" the vdsm version would be interesting.
But to the consumer the oVirt version for which it cna be used is
probably the most interesting - after all it should be a black box ;)

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

From alonbl at redhat.com  Thu Apr  3 11:03:54 2014
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Thu, 3 Apr 2014 07:03:54 -0400 (EDT)
Subject: [node-devel] Versioning of oVirt Node
In-Reply-To: <1396518325.3057.43.camel@fdeutsch-laptop.local>
References: <1396006625.2943.43.camel@fdeutsch-laptop.local>
	<1611733432.4095464.1396169829479.JavaMail.zimbra@redhat.com>
	<1396251915.3043.24.camel@fdeutsch-laptop.local>
	<890404270.4200435.1396255959839.JavaMail.zimbra@redhat.com>
	<1396516187.3057.38.camel@fdeutsch-laptop.local>
	<760216481.935128.1396518083947.JavaMail.zimbra@redhat.com>
	<1396518325.3057.43.camel@fdeutsch-laptop.local>
Message-ID: <1781260404.958120.1396523034984.JavaMail.zimbra@redhat.com>



----- 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: Thursday, April 3, 2014 12:45:25 PM
> Subject: Re: [node-devel] Versioning of oVirt Node
> 
> Am Donnerstag, den 03.04.2014, 05:41 -0400 schrieb Alon Bar-Lev:

<snip>

> > 
> > > > > 
> > > > > > 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?
> > > 
> > > Oh right. Well the "node" version can be retrieved by looking at the
> > > version of the contained ovirt-node pkg. We don't need to expose it in
> > > the name.
> > > 
> > > That's actually what I want to avoid - to expose the node version -
> > > because this isn't helpful to th euser - even worse - it is confusing.
> > 
> > On the contrary... the node version is the part that is important, this is
> > the upstream version of the component, and should not be hidden.
> 
> We keep the version for the "real" component which is the ovirt-node
> package.
> Further more we could say that the ovirt-node-iso component is a
> component on it's own with it's own version.

Component version that builds the output is important.
As a change in that component will result in different output.
So there must be a trace for that version.

> Because the ISO is squashing many packages I don't see a hard reason why
> it should have the version of the ovirt-node package.
> And my suggestion is to let the ovirt-node-iso component follow the
> overall/project version.

The version of the process that builds is important, for example, let's say you build an image using component-v1, then build another image using component-v2, now, you find a severe bug in component-v1 and want to fix only this bug and release component-v1.1, how can you do this, how can you know that you have component-v1, component-v2, component-v1.1 is v1.1 > v2 ?

> For us "No(o)dlers"" it would be interesting to see the ovirt-node
> version.
> For "vdsmlers" the vdsm version would be interesting.
> But to the consumer the oVirt version for which it cna be used is
> probably the most interesting - after all it should be a black box ;)

Even a black box should have a version to enable proper release engineering... There must be a way to trace back a component from output to source, and be able to rebuild it to produce the exact output. This is required so that this "black box" may fixed, bugs may be assigned to right version, bug will be resolved at right version etc...

Alon


From bproffit at redhat.com  Thu Apr  3 12:25:03 2014
From: bproffit at redhat.com (Brian Proffitt)
Date: Thu, 3 Apr 2014 08:25:03 -0400 (EDT)
Subject: Mailing List Changes
In-Reply-To: <218382315.1357192.1396527769057.JavaMail.zimbra@redhat.com>
Message-ID: <688277561.1358196.1396527903926.JavaMail.zimbra@redhat.com>

All:

We have started to implement the Arch/Engine-devel list changes.

Arch and engine-devel list subscribers are now subscribed to devel. (Arch users were also inadvertently subscribed to engine-devel, but that will be moot in about an hour.) 

At 1330 UTC (a little over one hour from now), the engine-devel mailing list will be shut down and its archives moved to devel.

Arch will remain in place, but all users there are recommended to start using devel for new conversations.

Thanks,
Brian


-- 
Brian Proffitt - oVirt Community Manager
Open Source and Standards, Red Hat - http://community.redhat.com
Phone: +1 574 383 9BKP
IRC: bkp @ OFTC


From alonbl at redhat.com  Fri Apr  4 16:31:56 2014
From: alonbl at redhat.com (Alon Bar-Lev)
Date: Fri, 4 Apr 2014 12:31:56 -0400 (EDT)
Subject: Attention: Mailing List Change
In-Reply-To: <432909486.4099248.1395859191777.JavaMail.zimbra@redhat.com>
References: <432909486.4099248.1395859191777.JavaMail.zimbra@redhat.com>
Message-ID: <1004613309.1544526.1396629116956.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Brian Proffitt" <bproffit at redhat.com>
> To: "arch" <arch at ovirt.org>
> Sent: Wednesday, March 26, 2014 8:39:51 PM
> Subject: Attention: Mailing List Change
> 
> All:
> 
> One of the long-standing requests in the oVirt community is the merging of
> the [arch] and [engine-devel] mailing lists. This note is an announcement
> that on Monday, March 31, this will get done.
> 
> What will happen:
> 
> 1) Subscribers from [arch] and [engine-devel] will be migrated to a new
> [devel] list.
> 2) Archives from [arch] (this list) will be left as is, and available for
> searching on the list.ovirt.org/mailman site.
> 3) Archived from [engine-devel] will be renamed to [devel]

Can we rename [devel] prefix to [ovirt-devel], it is confusing with other lists.
Same I guess to any ovirt list.

Thanks!

> 
> If you have any comments or concerns, let me know.
> 
> Thank you for your patience in this matter,
> Brian
> 
> --
> Brian Proffitt - oVirt Community Manager
> Open Source and Standards, Red Hat - http://community.redhat.com
> Phone: +1 574 383 9BKP
> IRC: bkp @ OFTC
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>