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

From: "Eyal Edri" <eedri@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "infra" <infra@ovirt.org>, "Kiril Nesenko" <kiril@redhat.com>, "Sandro Bonazzola" <sbonazzo@redhat.com> Sent: Sunday, January 5, 2014 8:46:39 PM Subject: Re: release repo structure and 3.3.2

current layout for stable is mostly links to 3.3 dir:

# tree . |-- iso -> /var/www/html/releases/3.2/iso |-- rpm | |-- EL -> /var/www/html/releases/3.3/rpm/EL | `-- Fedora | |-- 17 -> /var/www/html/releases/3.1/rpm/Fedora/17 | |-- 18 -> /var/www/html/releases/3.2/rpm/Fedora/18 | `-- 19 -> /var/www/html/releases/3.3/rpm/Fedora/19 |-- src -> /var/www/html/releases/3.3/src `-- tools -> /var/www/html/releases/3.3/tools

so i guess the links should be updates to point to 3.3.2 dir instead of 3.3

This method will not allow people to rollback. We should have single repo with rolling rpms, keeping previous released ones.

Eyal.

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

...

From: "Itamar Heim" <iheim@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "infra" <infra@ovirt.org>, "Kiril Nesenko" <kiril@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com> Sent: Sunday, January 5, 2014 7:55:19 PM Subject: Re: release repo structure and 3.3.2

On 01/01/2014 11:42 AM, Alon Bar-Lev wrote:

...

Hi,

For some reason there 3.3.2 z-stream was released in its own repository so people that are subscribed to stable[1] did not get it.

There is no much sense in releasing fix release that people do not get in simple "yum update".

Also the following is now broken of most packages' spec: Source0: http://ovirt.org/releases/stable/src/@PACKAGE_NAME@-@PACKAGE_VERSION@.tar.gz

For each minor we should have rolling repository, to reduce noise and provide service.

All released tarballs (sources) should be stored at fixed location to allow distro specific code to fetch, the location must be synced with what we publish.

Immediate action is to move the 3.3.2 content into the stable directory.

Regards, Alon Bar-Lev.

[1] http://resources.ovirt.org/releases/stable/ _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

kiril - was this fixed? _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

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

From: "Kiril Nesenko" <knesenko@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Eyal Edri" <eedri@redhat.com>, "Sandro Bonazzola" <sbonazzo@redhat.com>, "infra" <infra@ovirt.org> Sent: Monday, January 6, 2014 11:36:42 AM Subject: Re: release repo structure and 3.3.2

I moved the 3.3.2 content to the stable, should be ok now.

Once I will finish with upstream builds/releases/repos reorganization things will be much more clear than today.

You did not handle the source... Until this is resolved I cannot push the Gentoo release.

Kiril

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

...

From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "infra" <infra@ovirt.org>, "Kiril Nesenko" <kiril@redhat.com> Sent: Sunday, January 5, 2014 8:47:44 PM Subject: Re: release repo structure and 3.3.2

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

...

From: "Eyal Edri" <eedri@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Alon Bar-Lev" <alonbl@redhat.com>, "infra" <infra@ovirt.org>, "Kiril Nesenko" <kiril@redhat.com>, "Sandro Bonazzola" <sbonazzo@redhat.com> Sent: Sunday, January 5, 2014 8:46:39 PM Subject: Re: release repo structure and 3.3.2

current layout for stable is mostly links to 3.3 dir:

# tree . |-- iso -> /var/www/html/releases/3.2/iso |-- rpm | |-- EL -> /var/www/html/releases/3.3/rpm/EL | `-- Fedora | |-- 17 -> /var/www/html/releases/3.1/rpm/Fedora/17 | |-- 18 -> /var/www/html/releases/3.2/rpm/Fedora/18 | `-- 19 -> /var/www/html/releases/3.3/rpm/Fedora/19 |-- src -> /var/www/html/releases/3.3/src `-- tools -> /var/www/html/releases/3.3/tools

so i guess the links should be updates to point to 3.3.2 dir instead of 3.3

This method will not allow people to rollback. We should have single repo with rolling rpms, keeping previous released ones.

...

Eyal.

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

...

From: "Itamar Heim" <iheim@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "infra" <infra@ovirt.org>, "Kiril Nesenko" <kiril@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com> Sent: Sunday, January 5, 2014 7:55:19 PM Subject: Re: release repo structure and 3.3.2

On 01/01/2014 11:42 AM, Alon Bar-Lev wrote:

...

Hi,

For some reason there 3.3.2 z-stream was released in its own repository so people that are subscribed to stable[1] did not get it.

There is no much sense in releasing fix release that people do not get in simple "yum update".

Also the following is now broken of most packages' spec: Source0: http://ovirt.org/releases/stable/src/@PACKAGE_NAME@-@PACKAGE_VERSION@.tar.gz

For each minor we should have rolling repository, to reduce noise and provide service.

All released tarballs (sources) should be stored at fixed location to allow distro specific code to fetch, the location must be synced with what we publish.

Immediate action is to move the 3.3.2 content into the stable directory.

Regards, Alon Bar-Lev.

[1] http://resources.ovirt.org/releases/stable/ _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

kiril - was this fixed? _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

On Tue, Jan 07, 2014 at 03:31:12PM +0100, Sandro Bonazzola wrote:

Il 01/01/2014 10:42, Alon Bar-Lev ha scritto:

...

For some reason there 3.3.2 z-stream was released in its own repository so people that are subscribed to stable[1] did not get it.

Why not? stable release had ovirt-release-10 which enabled both stable and 3.3.2 repository by yum updating it.

I think that means a user has to update twice. First ensure ovirt-release is updated and then ensure ovirt is updated.

Il 01/01/2014 10:42, Alon Bar-Lev ha scritto:

...

Hi,

For some reason there 3.3.2 z-stream was released in its own repositor= y so people that are subscribed to stable[1] did not get it. =20 Why not? stable release had ovirt-release-10 which enabled both stable and 3.3.2= repository by yum updating it. =20

There is no much sense in releasing fix release that people do not get= in simple "yum update".

Also the following is now broken of most packages' spec: Source0: http://ovirt.org/releases/stable/src/@PACKAGE_NAME@-@P= ACKAGE_VERSION@.tar.gz

For each minor we should have rolling repository, to reduce noise and =

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UQOVhnEdnAfdTdS57IlOdxiBx98VKmWw8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable El 07/01/14 15:31, Sandro Bonazzola escribi=F3: provide service.

...

All released tarballs (sources) should be stored at fixed location to =

allow distro specific code to fetch, the location must be synced with wha= t we publish.

...

Immediate action is to move the 3.3.2 content into the stable director=

y. =20 So previous request of having each release in its own repository has be= en retired? Or is it combined? Do we want stable to be a rolling repository and have also a repository= for each version? I'm not against having rolling packages in just one stable repository, = I just want to understand what is the desired structure of the repositori= es.

I am, having a stable repository with rolling rpms is a lot more hard to = manage and maintain than having separated individual complete repos. Because what we are actually delivering is not a specific rpm, but the wh= ole set, that is, one repository with the set of rpms that were tested togeth= er and validated. If at any point you want to mix them, you still can adding the= other repos. For updates just updating the directory where the 'stable' link points ge= ts it done. For rollbacks you'll have to configure the old repo. That is not as annoy= ing as it might seem, because when you enable the stable repo, you want to have = the stable version, that changes with time. If you want to rollback to a prev= ious version then just use that versions specific repo. At much we can provide= a link like 'previous_stable' so if you want to rollback to the previous version= you can use --enablerepo=3Dprevious_version easily, but if you want to keep u= sing that, you should point directly to the specific version you want tot use.= Creating a new repository using is almost as cheap (on hard disk space) a= s having a rolling repository, if you use hard links, so we can create lot'= s of them, specially for small changes from one to another. The only drawback that I see is when you have to release a minor change i= n one the the rpms, for example, to fix a critical bug, the repo will not inclu= de the old package, but I'm not sure if that's really a drawback... if you reall= y need that package without the critical fix (you should not) you can have it ch= anging to that specific repository. The internal naming of the repos does not re= ally matter, having to point to the repo 3.3.3-beta.2 to get the second 'respi= n' of the 3.3.3 beta repo is not a big issue I think. The advantages are many, the most importants I see: - Easy management: * no need to go version hunting in the repo to remove/add rpms * you should never get a repo with version combinations that are not t= ested * it's a lot easier to get rid of old repos, and to move them around a= s they are independent * no broken links, right now stable repo is full of links to other rep= os, so removing those repos leave the links broken, you have to go checking= if someone links to them (or their internal directories) if you have to= clean up old versions - Testing, it's a lot easier to reproduce any error found, as you can just use the same repo and you'll get the same version set. What do you think?

=20

...

Regards, Alon Bar-Lev.

[1] http://resources.ovirt.org/releases/stable/

=20 =20

--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --UQOVhnEdnAfdTdS57IlOdxiBx98VKmWw8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJS1qioAAoJEEBxx+HSYmnDN5sH/1ZDK4QTr0Ktg+aoYVajkSr+ aVJCifIE9SpcDwS8O9b296gTc+q7cSzZ3wwSzk/cczGRCx5zsWlI1sTPE5xW3usD 0uCi0OzdLeefq5lYhFc4mI04GZCxeQ7HNOtVZx5HFam8dRPYoGPtzfPGMPw0Yku7 K9p45oJowGZhOBMVHD1kSnbuYCTvBM17nSb+u04FO5ZmkIF8APBacSNkM8et7DxH RVuoX6udklB7058lYvKP6h52aMjgF6HVBnUjaIf82YH0WslwrfbRs1UgXXJiK/HG sxJQok+ZTOWrj68ybdv3Kcx92K5bRwk4WSjpcsK2vVCr8+NA5swiMUqyAwzKmDM= =meiM -----END PGP SIGNATURE----- --UQOVhnEdnAfdTdS57IlOdxiBx98VKmWw8--

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rH8JAPLilKLwTq03sJMa0XiwfrPV3vPb4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El mi=C3=A9 15 ene 2014 16:30:00 CET, Alon Bar-Lev escribi=C3=B3:

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

...

From: "David Caro" <dcaroest@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Alon Bar-Lev" <alonbl@r=

...

Cc: "Kiril Nesenko" <kiril@redhat.com> Sent: Wednesday, January 15, 2014 5:26:32 PM Subject: Re: release repo structure and 3.3.2

El 07/01/14 15:31, Sandro Bonazzola escribi=C3=B3:

...

Il 01/01/2014 10:42, Alon Bar-Lev ha scritto:

...

Hi,

For some reason there 3.3.2 z-stream was released in its own reposit= ory so people that are subscribed to stable[1] did not get it.

Why not? stable release had ovirt-release-10 which enabled both stable and 3.3= =2E2 repository by yum updating it.

...

There is no much sense in releasing fix release that people do not g=

et in

...

simple "yum update".

Also the following is now broken of most packages' spec: Source0: http://ovirt.org/releases/stable/src/@PACKAGE_NAME@-@PACKAGE_VERSION= @.tar.gz

For each minor we should have rolling repository, to reduce noise an= d provide service.

All released tarballs (sources) should be stored at fixed location t= o allow distro specific code to fetch, the location must be synced wit= h what we publish.

Immediate action is to move the 3.3.2 content into the stable direct= ory.

So previous request of having each release in its own repository has = been retired? Or is it combined? Do we want stable to be a rolling repository and have also a reposito= ry for each version? I'm not against having rolling packages in just one stable repository= , I just want to understand what is the desired structure of the reposito= ries.

I am, having a stable repository with rolling rpms is a lot more hard = to manage and maintain than having separated individual complete repos.

Because what we are actually delivering is not a specific rpm, but the= whole set, that is, one repository with the set of rpms that were tested tog= ether and validated. If at any point you want to mix them, you still can adding =

...

other repos.

For updates just updating the directory where the 'stable' link points= gets it done.

For rollbacks you'll have to configure the old repo. That is not as an= noying as it might seem, because when you enable the stable repo, you want to ha= ve the stable version, that changes with time. If you want to rollback to a p= revious version then just use that versions specific repo. At much we can prov= ide a link like 'previous_stable' so if you want to rollback to the previous vers= ion you can use --enablerepo=3Dprevious_version easily, but if you want to kee=

edhat.com>, "infra" <infra@ovirt.org> the p using

...

that, you should point directly to the specific version you want tot u= se.

Creating a new repository using is almost as cheap (on hard disk space= ) as having a rolling repository, if you use hard links, so we can create l= ot's of them, specially for small changes from one to another.

The only drawback that I see is when you have to release a minor chang= e in one the the rpms, for example, to fix a critical bug, the repo will not in= clude the old package, but I'm not sure if that's really a drawback... if you re= ally need that package without the critical fix (you should not) you can have it=

...

changing to that specific repository. The internal naming of the repos does not= really matter, having to point to the repo 3.3.3-beta.2 to get the second 're= spin' of the 3.3.3 beta repo is not a big issue I think.

The advantages are many, the most importants I see: - Easy management: * no need to go version hunting in the repo to remove/add rpms * you should never get a repo with version combinations that are no= t tested * it's a lot easier to get rid of old repos, and to move them aroun= d as they are independent * no broken links, right now stable repo is full of links to other = repos, so removing those repos leave the links broken, you have to go check= ing if someone links to them (or their internal directories) if you have= to clean up old versions - Testing, it's a lot easier to reproduce any error found, as you can=

...

just use the same repo and you'll get the same version set.

What do you think?

And you do not allow quick fix of issues found in various of packages. Why not? You can create a new repo based in the previous one that=20 includes the fixed packages. It's cheap!

Although there is /some/ sense in syncing minor releases, I do not see =

any reason of syncing z-stream.

I think that you do not trust individual maintainer to provide z-stream= s.

A change in z-stream should not be exposed (unless is fixing) an extern= al interface.

I don't think it should be hidden neither, just make clear that those=20 are not builds to be used widely, maybe just putting it under another=20 directory (not releases). Where only promoted repos can go (meaning,=20 not everyone can put repos there). For example: repos/releases -> for repos that have been tested and we want to publish repos/testing -> for any temporary generated repo, that is not fully=20 tested and not ready for be used widely That way you make sure that if anyone is using a repo that is not fully=20 tested, is because he wants to, but you don't forbid it.

Alon

...

...

...

Regards, Alon Bar-Lev.

[1] http://resources.ovirt.org/releases/stable/

-- David Caro

Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605

-- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --rH8JAPLilKLwTq03sJMa0XiwfrPV3vPb4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJS1q2vAAoJEEBxx+HSYmnD4bIH/3K4M9CtZY+dSBiB4F43UZIx TvIvlhqY91A7lVzMDXrmASqJmDRMT4Wcuh317W69cp6EAN2g6SiZbGmMqDWIqU9m ourCWTzHlMBXWIXKDRKhAmUB0XK2PnZeBV4krVxABXW9Lc1AATCdHLb7fYKuftJI 9mShPv0s2jLsWbMPfAgI/NJVFda1yg5JQm3b4Q0+iBIokZioDcSe8UlyLMWHA7E9 ygtI9m3V96tEQg/GsFp+3/KizVPD/qqGp/5VH6AhifQxjRoFvKLPBrv3xur7lKPx gmJ1vdhFo/gpr6RMWZydmVFwdlZEe66VljAgB8tz/Xk17m+G5JksXW9UDpB7HcU= =mbvQ -----END PGP SIGNATURE----- --rH8JAPLilKLwTq03sJMa0XiwfrPV3vPb4--

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Mdtdq0OpWWeWKSHMEaaBTtuR5rUPjTbeD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El mi=C3=A9 15 ene 2014 19:04:04 CET, Alon Bar-Lev escribi=C3=B3:

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

...

From: "David Caro" <dcaroest@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "infra" <infra@ovirt.org= , "Kiril Nesenko" <kiril@redhat.com> Sent: Wednesday, January 15, 2014 5:47:59 PM Subject: Re: release repo structure and 3.3.2

El mi=C3=A9 15 ene 2014 16:30:00 CET, Alon Bar-Lev escribi=C3=B3:

...

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

...

From: "David Caro" <dcaroest@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Alon Bar-Lev" <alonbl@redhat.com>, "infra" <infra@ovirt.org> Cc: "Kiril Nesenko" <kiril@redhat.com> Sent: Wednesday, January 15, 2014 5:26:32 PM Subject: Re: release repo structure and 3.3.2

El 07/01/14 15:31, Sandro Bonazzola escribi=C3=B3:

...

Il 01/01/2014 10:42, Alon Bar-Lev ha scritto:

...

Hi,

For some reason there 3.3.2 z-stream was released in its own repos=

itory

...

...

...

...

...

so people that are subscribed to stable[1] did not get it.

Why not? stable release had ovirt-release-10 which enabled both stable and 3= =2E3.2 repository by yum updating it.

...

There is no much sense in releasing fix release that people do not=

get

...

in simple "yum update".

Also the following is now broken of most packages' spec: Source0: http://ovirt.org/releases/stable/src/@PACKAGE_NAME@-@PACKAGE_VERSI= ON@.tar.gz

For each minor we should have rolling repository, to reduce noise = and provide service.

All released tarballs (sources) should be stored at fixed location= to allow distro specific code to fetch, the location must be synced w= ith what we publish.

Immediate action is to move the 3.3.2 content into the stable dire= ctory.

So previous request of having each release in its own repository ha= s been retired? Or is it combined? Do we want stable to be a rolling repository and have also a reposi= tory for each version? I'm not against having rolling packages in just one stable reposito= ry, I just want to understand what is the desired structure of the repositories.

I am, having a stable repository with rolling rpms is a lot more har= d to manage and maintain than having separated individual complete repos.

Because what we are actually delivering is not a specific rpm, but t= he whole set, that is, one repository with the set of rpms that were tested together and validated. If at any point you want to mix them, you still can addin= g the other repos.

For updates just updating the directory where the 'stable' link poin= ts gets it done.

For rollbacks you'll have to configure the old repo. That is not as annoying as it might seem, because when you enable the stable repo, you want to = have the stable version, that changes with time. If you want to rollback to a=

...

...

...

previous version then just use that versions specific repo. At much we can pr= ovide a link like 'previous_stable' so if you want to rollback to the previous ve= rsion you can use --enablerepo=3Dprevious_version easily, but if you want to k= eep using that, you should point directly to the specific version you want tot= use.

Creating a new repository using is almost as cheap (on hard disk spa= ce) as having a rolling repository, if you use hard links, so we can create= lot's of them, specially for small changes from one to another.

The only drawback that I see is when you have to release a minor cha= nge in one the the rpms, for example, to fix a critical bug, the repo will not include the old package, but I'm not sure if that's really a drawback... if you = really need that package without the critical fix (you should not) you can have = it changing to that specific repository. The internal naming of the repos does n= ot really matter, having to point to the repo 3.3.3-beta.2 to get the second 'respin' of the 3.3.3 beta repo is not a big issue I think.

The advantages are many, the most importants I see: - Easy management: * no need to go version hunting in the repo to remove/add rpms * you should never get a repo with version combinations that are = not tested * it's a lot easier to get rid of old repos, and to move them aro= und as they are independent * no broken links, right now stable repo is full of links to othe= r repos, so removing those repos leave the links broken, you have to go che= cking if someone links to them (or their internal directories) if you ha= ve to clean up old versions - Testing, it's a lot easier to reproduce any error found, as you c= an just use the same repo and you'll get the same version set.

What do you think?

...

And you do not allow quick fix of issues found in various of packages= =2E Why not? You can create a new repo based in the previous one that includes the fixed packages. It's cheap!

who is you? In this case you is the person/process/chimpanzee that is in charge of=20 publishing the fixed packages to the correct environment

how do I push fix to users for z-stream of packages as otopi, ovirt-hos= t-deploy, log collector and such? Exactly the same way you do it for engine or vdsm

why is these components' release cycle should be at same schedule of ov= irt-engine which is heavy and slow? It should not.

...

...

Although there is /some/ sense in syncing minor releases, I do not se=

...

...

reason of syncing z-stream.

...

I think that you do not trust individual maintainer to provide z-stre= ams.

A change in z-stream should not be exposed (unless is fixing) an exte= rnal interface.

I don't think it should be hidden neither, just make clear that those are not builds to be used widely, maybe just putting it under another directory (not releases). Where only promoted repos can go (meaning, not everyone can put repos there). For example: repos/releases -> for repos that have been tested and we want to publi= sh repos/testing -> for any temporary generated repo, that is not fully tested and not ready for be used widely

why not released? only because engine is slow? I do not understand. I don't even understand your question. We got lost at some point. I'll=20

e any try to explain a little more what I said before, maybe that will=20 clarify the issue to you. You said that a change in z-stream should not be exposed, for that I=20 understand for that that a package that is meant to go to a z-stream=20 should not be exposed to the general public. I think that it should,=20 but it must be clear to the public that it's not yet ready (I suppose=20 that's the reason you don't want it public), so they use it at their=20 own risk. And separating the repos into two seems a good wat for making=20 that clear (another one is adding a suffix to the repo name for=20 example).

...

That way you make sure that if anyone is using a repo that is not full=

...

tested, is because he wants to, but you don't forbid it.

why do you think that someone is releasing untested packages? I do not think that someone is releasing untested packages. That=20 sentence comes from the hypothetical situation where a repository that=20 is not meant to be used by the general public (I said untested, but it=20 could be for any other reason) is made public using a different url=20

y than the repos that are meant to be widely used. Part of the advantages of that system is the ease to run tests on=20 specific version sets (repos). That we do not do right now (at least=20 *upstream*) but I think would be done in the near future.

...

...

Alon

...

...

...

Regards, Alon Bar-Lev.

[1] http://resources.ovirt.org/releases/stable/

-- David Caro

Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605

-- David Caro

Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605

-- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --Mdtdq0OpWWeWKSHMEaaBTtuR5rUPjTbeD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJS1yCQAAoJEEBxx+HSYmnDm50H/ig7nM9EidzwOWrcPmWW1907 26fZUjcy17uLa8dnbnaDZSNeL4EzLgLnJz8ftovSIFQ2MKzB6D2M5EgFHU7DNltm Jk0p/DM8JTgEb5lAPKrBbzlPx3eF8Dfodmyi8laaaClm+i7D4cZaM6qNxKXrncTW K562ymN7YBn13r+/9tQVoGeLl93itnJ813ez9MvCrPOCvMTITs+idOwfOniVcjrl 3050hBChkwbZ3o7XM1ZgO3hiPOYf5GqdXDa3+EZ6G5hXiTELuIrmAPbQWcFlcSIg mP1z4Ygz76k7C320jjXg2dv45Y4Yar/f3yVoBj/26nfC3hanf060VJwLCFX5+Jg= =xowh -----END PGP SIGNATURE----- --Mdtdq0OpWWeWKSHMEaaBTtuR5rUPjTbeD--

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --t5w3p6BN7fiHDlmCntRnBv3wjhX0SJU7D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El jue 16 ene 2014 01:04:33 CET, Alon Bar-Lev escribi=C3=B3:

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

...

From: "David Caro" <dcaroest@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "infra" <infra@ovirt.org= , "Kiril Nesenko" <kiril@redhat.com> Sent: Thursday, January 16, 2014 1:58:08 AM Subject: Re: release repo structure and 3.3.2

El mi=C3=A9 15 ene 2014 19:04:04 CET, Alon Bar-Lev escribi=C3=B3:

...

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

...

From: "David Caro" <dcaroest@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "infra" <infra@ovirt.o=

...

...

...

"Kiril Nesenko" <kiril@redhat.com> Sent: Wednesday, January 15, 2014 5:47:59 PM Subject: Re: release repo structure and 3.3.2

El mi=C3=A9 15 ene 2014 16:30:00 CET, Alon Bar-Lev escribi=C3=B3:

...

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

...

From: "David Caro" <dcaroest@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Alon Bar-Lev" <alonbl@redhat.com>, "infra" <infra@ovirt.org> Cc: "Kiril Nesenko" <kiril@redhat.com> Sent: Wednesday, January 15, 2014 5:26:32 PM Subject: Re: release repo structure and 3.3.2

El 07/01/14 15:31, Sandro Bonazzola escribi=C3=B3: > Il 01/01/2014 10:42, Alon Bar-Lev ha scritto: >> Hi, >> >> For some reason there 3.3.2 z-stream was released in its own >> repository >> so >> people that are subscribed to stable[1] did not get it. > > Why not? > stable release had ovirt-release-10 which enabled both stable and=

3.3.2

...

...

> repository by yum updating it. > >> >> There is no much sense in releasing fix release that people do n= ot get >> in >> simple "yum update". >> >> Also the following is now broken of most packages' spec: >> Source0: >> http://ovirt.org/releases/stable/src/@PACKAGE_NAME@-@PACKAGE_VER= SION@.tar.gz >> >> For each minor we should have rolling repository, to reduce nois= e and >> provide service. >> >> All released tarballs (sources) should be stored at fixed locati= on to >> allow distro specific code to fetch, the location must be synced= with >> what we publish. >> >> Immediate action is to move the 3.3.2 content into the stable >> directory. > > So previous request of having each release in its own repository = has > been > retired? > Or is it combined? > Do we want stable to be a rolling repository and have also a repo= sitory > for > each version? > I'm not against having rolling packages in just one stable reposi= tory, > I > just want to understand what is the desired structure of the > repositories.

I am, having a stable repository with rolling rpms is a lot more h= ard to manage and maintain than having separated individual complete repos.

Because what we are actually delivering is not a specific rpm, but=

rg>, the

...

...

...

...

...

whole set, that is, one repository with the set of rpms that were tested=

...

...

...

...

...

together and validated. If at any point you want to mix them, you still can add= ing the other repos.

For updates just updating the directory where the 'stable' link po= ints gets it done.

For rollbacks you'll have to configure the old repo. That is not a= s annoying as it might seem, because when you enable the stable repo, you want t= o have the stable version, that changes with time. If you want to rollback to= a previous version then just use that versions specific repo. At much we can provide a link like 'previous_stable' so if you want to rollback to the previous version you can use --enablerepo=3Dprevious_version easily, but if you want to= keep using that, you should point directly to the specific version you want t= ot use.

Creating a new repository using is almost as cheap (on hard disk s= pace) as having a rolling repository, if you use hard links, so we can crea= te lot's of them, specially for small changes from one to another.

The only drawback that I see is when you have to release a minor c= hange in one the the rpms, for example, to fix a critical bug, the repo will no= t include the old package, but I'm not sure if that's really a drawback... if yo= u really need that package without the critical fix (you should not) you can hav= e it changing to that specific repository. The internal naming of the repos does= not really matter, having to point to the repo 3.3.3-beta.2 to get the second=

...

...

...

...

...

'respin' of the 3.3.3 beta repo is not a big issue I think.

The advantages are many, the most importants I see: - Easy management: * no need to go version hunting in the repo to remove/add rpms * you should never get a repo with version combinations that ar= e not tested * it's a lot easier to get rid of old repos, and to move them a= round as they are independent * no broken links, right now stable repo is full of links to ot= her repos, so removing those repos leave the links broken, you have to go checking if someone links to them (or their internal directories) if you = have to clean up old versions - Testing, it's a lot easier to reproduce any error found, as you= can just use the same repo and you'll get the same version set.

What do you think?

...

And you do not allow quick fix of issues found in various of packag= es. Why not? You can create a new repo based in the previous one that includes the fixed packages. It's cheap!

who is you? In this case you is the person/process/chimpanzee that is in charge of=

...

publishing the fixed packages to the correct environment

...

how do I push fix to users for z-stream of packages as otopi, ovirt-host-deploy, log collector and such? Exactly the same way you do it for engine or vdsm

...

why is these components' release cycle should be at same schedule of ovirt-engine which is heavy and slow? It should not.

...

...

...

Although there is /some/ sense in syncing minor releases, I do not =

see

...

...

...

any reason of syncing z-stream.

...

I think that you do not trust individual maintainer to provide z-st= reams.

A change in z-stream should not be exposed (unless is fixing) an ex= ternal interface.

I don't think it should be hidden neither, just make clear that thos= e are not builds to be used widely, maybe just putting it under anothe= r directory (not releases). Where only promoted repos can go (meaning,=

...

...

...

not everyone can put repos there). For example: repos/releases -> for repos that have been tested and we want to pub= lish repos/testing -> for any temporary generated repo, that is not fully=

...

...

...

tested and not ready for be used widely

why not released? only because engine is slow? I do not understand. I don't even understand your question. We got lost at some point. I'll=

...

try to explain a little more what I said before, maybe that will clarify the issue to you. You said that a change in z-stream should not be exposed, for that I understand for that that a package that is meant to go to a z-stream should not be exposed to the general public. I think that it should, but it must be clear to the public that it's not yet ready (I suppose that's the reason you don't want it public), so they use it at their own risk. And separating the repos into two seems a good wat for makin= g that clear (another one is adding a suffix to the repo name for example).

...

...

That way you make sure that if anyone is using a repo that is not fu=

lly

...

...

tested, is because he wants to, but you don't forbid it.

why do you think that someone is releasing untested packages? I do not think that someone is releasing untested packages. That sentence comes from the hypothetical situation where a repository that=

...

is not meant to be used by the general public (I said untested, but it=

...

could be for any other reason) is made public using a different url than the repos that are meant to be widely used.

Part of the advantages of that system is the ease to run tests on specific version sets (repos). That we do not do right now (at least *upstream*) but I think would be done in the near future.

I will try to explain again.

There is no actual relationship between packages, these could have been= provided asynchronous by multiple sources and maintainers regardless of = the ovrit project, just like libvirt or sanlock or any other 10000 depend= encies we have outside of the scope of the project.

That's not true, the relation is that they are provided by the same=20 repository and that they are maintained by the same community. Yes,=20 they could have been provided by multiple sources and maintainers, but=20 they were not.

Trying to control the release cycle only because we have two fat compon= ents is something that should be avoided. The model I exposed does not care if you create a new repository each=20 hour changing just one package or you create the repository on time a=20 year. What it's true is that it will be recreated when ANY (one or=20 more) of the packages included changes.

So far we have successfully released packages async with no regressions=

nor issues, and quickly solved user issues. There is absolutely no reaso= n to stop this offering. Yes, that in the last weeks sandro and me (mostly me) spent more than=20 two days trying to create a couple releases with the old process. It's=20 hard to maintain and I personally prefer focusing on another tasks than=20 searching rpm versions and trying to figure out what can be=20 deleted/moved and what can't. A proved way to improve things is to=20 change them, try new ways, if you do not change you are waiting for the=20 environment to do so, and that's usually really hard to achieve. Nothing suggests that adopting the process that I explained will affect=20 the user experience substantially (if think otherwise, please=20 elaborate).

...

...

...

...

Alon

...

> >> Regards, >> Alon Bar-Lev. >> >> [1] http://resources.ovirt.org/releases/stable/ >> > >

-- David Caro

Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605

-- David Caro

Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605

-- David Caro

Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605

-- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --t5w3p6BN7fiHDlmCntRnBv3wjhX0SJU7D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJS1ylEAAoJEEBxx+HSYmnDZygH/ifcO/RYEppdTQhqdBX84VAG v83/g2+KfklfenlEFCbZ0+hla/UtupChPbFsGnAddiPiRUHZ+yq+iMXIY/HPhBIw z4tqqgsSHIc9XdTOgXkpNWeZhKj6SFiZbKeSVKrixvppswMYAsJFeXFR3Zx06vsH svSP5o0P58kZ6YWZU3119mgzhV4Q/0nWkVjOtF5CC8UbqfT9+9Y0BvevMhCk4jz+ rarxbq3+/VSowM4uWeTtUqTJymsaoEeI8lXKP57SoNmsYViwSzzZudfD6TrMpPXP 7eszlCPgPgCu4fqhBLipZovqw/rg2rgCMhxA8DPTII+nq66bQj0ZLHjj/aF4HNw= =EXnp -----END PGP SIGNATURE----- --t5w3p6BN7fiHDlmCntRnBv3wjhX0SJU7D--

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sgcf4aCB1pRufHv0vxXe0rmc66jEnh2iX Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El jue 16 ene 2014 01:39:50 CET, Alon Bar-Lev escribi=C3=B3:

I won't argue more, obviously, you do not understand the point of distr=

ibuted management. Thanks Alon, always so useful.

But just think why don't we build large monolithic software.

Anyone thinks the same way Alon does? If so, can anyone explain me he's position? (As it seems he's not=20 willing to do so) Also any other opinions? Other Ideas?

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

...

From: "David Caro" <dcaroest@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "infra" <infra@ovirt.org= , "Kiril Nesenko" <kiril@redhat.com> Sent: Thursday, January 16, 2014 2:35:16 AM Subject: Re: release repo structure and 3.3.2

El jue 16 ene 2014 01:04:33 CET, Alon Bar-Lev escribi=C3=B3:

...

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

...

From: "David Caro" <dcaroest@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "infra" <infra@ovirt.o=

...

...

...

"Kiril Nesenko" <kiril@redhat.com> Sent: Thursday, January 16, 2014 1:58:08 AM Subject: Re: release repo structure and 3.3.2

El mi=C3=A9 15 ene 2014 19:04:04 CET, Alon Bar-Lev escribi=C3=B3:

...

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

...

From: "David Caro" <dcaroest@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "infra" <infra@ovirt=

=2Eorg>,

...

...

"Kiril Nesenko" <kiril@redhat.com> Sent: Wednesday, January 15, 2014 5:47:59 PM Subject: Re: release repo structure and 3.3.2

El mi=C3=A9 15 ene 2014 16:30:00 CET, Alon Bar-Lev escribi=C3=B3: > > > ----- Original Message ----- >> From: "David Caro" <dcaroest@redhat.com> >> To: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Alon Bar-Lev" >> <alonbl@redhat.com>, "infra" <infra@ovirt.org> >> Cc: "Kiril Nesenko" <kiril@redhat.com> >> Sent: Wednesday, January 15, 2014 5:26:32 PM >> Subject: Re: release repo structure and 3.3.2 >> >> El 07/01/14 15:31, Sandro Bonazzola escribi=C3=B3: >>> Il 01/01/2014 10:42, Alon Bar-Lev ha scritto: >>>> Hi, >>>> >>>> For some reason there 3.3.2 z-stream was released in its own >>>> repository >>>> so >>>> people that are subscribed to stable[1] did not get it. >>> >>> Why not? >>> stable release had ovirt-release-10 which enabled both stable a= nd >>> 3.3.2 >>> repository by yum updating it. >>> >>>> >>>> There is no much sense in releasing fix release that people do= not >>>> get >>>> in >>>> simple "yum update". >>>> >>>> Also the following is now broken of most packages' spec: >>>> Source0: >>>> http://ovirt.org/releases/stable/src/@PACKAGE_NAME@-@PACKAGE_V= ERSION@.tar.gz >>>> >>>> For each minor we should have rolling repository, to reduce no= ise >>>> and >>>> provide service. >>>> >>>> All released tarballs (sources) should be stored at fixed loca= tion >>>> to >>>> allow distro specific code to fetch, the location must be sync= ed >>>> with >>>> what we publish. >>>> >>>> Immediate action is to move the 3.3.2 content into the stable >>>> directory. >>> >>> So previous request of having each release in its own repositor= y has >>> been >>> retired? >>> Or is it combined? >>> Do we want stable to be a rolling repository and have also a >>> repository >>> for >>> each version? >>> I'm not against having rolling packages in just one stable >>> repository, >>> I >>> just want to understand what is the desired structure of the >>> repositories. >> >> I am, having a stable repository with rolling rpms is a lot more= hard >> to >> manage >> and maintain than having separated individual complete repos. >> >> Because what we are actually delivering is not a specific rpm, b= ut the >> whole >> set, that is, one repository with the set of rpms that were test= ed >> together >> and >> validated. If at any point you want to mix them, you still can a=

...

...

...

...

...

>> the >> other >> repos. >> >> For updates just updating the directory where the 'stable' link =

rg>, dding points

...

...

...

...

...

>> gets >> it done. >> >> For rollbacks you'll have to configure the old repo. That is not= as >> annoying >> as >> it might seem, because when you enable the stable repo, you want= to >> have >> the >> stable version, that changes with time. If you want to rollback = to a >> previous >> version then just use that versions specific repo. At much we ca= n >> provide >> a >> link >> like 'previous_stable' so if you want to rollback to the previou= s >> version >> you >> can use --enablerepo=3Dprevious_version easily, but if you want = to keep >> using >> that, you should point directly to the specific version you want= tot >> use. >> >> Creating a new repository using is almost as cheap (on hard disk=

...

...

...

...

...

>> space) >> as >> having a rolling repository, if you use hard links, so we can cr= eate >> lot's >> of >> them, specially for small changes from one to another. >> >> The only drawback that I see is when you have to release a minor=

...

...

...

...

...

>> change >> in >> one >> the the rpms, for example, to fix a critical bug, the repo will = not >> include >> the >> old package, but I'm not sure if that's really a drawback... if = you >> really >> need >> that package without the critical fix (you should not) you can h= ave it >> changing >> to that specific repository. The internal naming of the repos do= es not >> really >> matter, having to point to the repo 3.3.3-beta.2 to get the seco= nd >> 'respin' >> of >> the 3.3.3 beta repo is not a big issue I think. >> >> The advantages are many, the most importants I see: >> - Easy management: >> * no need to go version hunting in the repo to remove/add rpm= s >> * you should never get a repo with version combinations that = are >> not >> tested >> * it's a lot easier to get rid of old repos, and to move them=

...

...

...

...

...

>> around >> as >> they >> are independent >> * no broken links, right now stable repo is full of links to = other >> repos, >> so >> removing those repos leave the links broken, you have to go=

...

...

...

...

...

>> checking >> if >> someone links to them (or their internal directories) if yo= u have >> to >> clean >> up old versions >> - Testing, it's a lot easier to reproduce any error found, as y= ou can >> just use the same repo and you'll get the same version set. >> >> What do you think? >

> And you do not allow quick fix of issues found in various of pack= ages. Why not? You can create a new repo based in the previous one that includes the fixed packages. It's cheap!

who is you? In this case you is the person/process/chimpanzee that is in charge = of publishing the fixed packages to the correct environment

...

how do I push fix to users for z-stream of packages as otopi, ovirt-host-deploy, log collector and such? Exactly the same way you do it for engine or vdsm

...

why is these components' release cycle should be at same schedule o= f ovirt-engine which is heavy and slow? It should not.

...

...

> > Although there is /some/ sense in syncing minor releases, I do no=

t see

...

...

> any > reason of syncing z-stream. >

> I think that you do not trust individual maintainer to provide > z-streams. > > A change in z-stream should not be exposed (unless is fixing) an > external > interface.

I don't think it should be hidden neither, just make clear that th= ose are not builds to be used widely, maybe just putting it under anot= her directory (not releases). Where only promoted repos can go (meanin= g, not everyone can put repos there). For example: repos/releases -> for repos that have been tested and we want to p= ublish repos/testing -> for any temporary generated repo, that is not ful= ly tested and not ready for be used widely

why not released? only because engine is slow? I do not understand.=

...

...

...

I don't even understand your question. We got lost at some point. I'= ll try to explain a little more what I said before, maybe that will clarify the issue to you. You said that a change in z-stream should not be exposed, for that I=

...

...

...

understand for that that a package that is meant to go to a z-stream=

...

...

...

should not be exposed to the general public. I think that it should,=

...

...

...

but it must be clear to the public that it's not yet ready (I suppos= e that's the reason you don't want it public), so they use it at their=

...

...

...

own risk. And separating the repos into two seems a good wat for mak= ing that clear (another one is adding a suffix to the repo name for example).

...

...

That way you make sure that if anyone is using a repo that is not =

...

...

tested, is because he wants to, but you don't forbid it.

why do you think that someone is releasing untested packages? I do not think that someone is releasing untested packages. That sentence comes from the hypothetical situation where a repository th= at is not meant to be used by the general public (I said untested, but = it could be for any other reason) is made public using a different url

fully than the repos that are meant to be widely used.

Part of the advantages of that system is the ease to run tests on specific version sets (repos). That we do not do right now (at least=

...

...

...

*upstream*) but I think would be done in the near future.

I will try to explain again.

There is no actual relationship between packages, these could have be= en provided asynchronous by multiple sources and maintainers regardless = of the ovrit project, just like libvirt or sanlock or any other 10000 dependencies we have outside of the scope of the project.

That's not true, the relation is that they are provided by the same repository and that they are maintained by the same community. Yes, they could have been provided by multiple sources and maintainers, but=

...

they were not.

...

Trying to control the release cycle only because we have two fat comp= onents is something that should be avoided. The model I exposed does not care if you create a new repository each hour changing just one package or you create the repository on time a year. What it's true is that it will be recreated when ANY (one or more) of the packages included changes.

...

So far we have successfully released packages async with no regressio=

ns nor

...

issues, and quickly solved user issues. There is absolutely no reason= to stop this offering. Yes, that in the last weeks sandro and me (mostly me) spent more than two days trying to create a couple releases with the old process. It's=

...

hard to maintain and I personally prefer focusing on another tasks tha= n searching rpm versions and trying to figure out what can be deleted/moved and what can't. A proved way to improve things is to change them, try new ways, if you do not change you are waiting for th= e environment to do so, and that's usually really hard to achieve. Nothing suggests that adopting the process that I explained will affec= t the user experience substantially (if think otherwise, please elaborate).

...

...

...

...

> > Alon > >> >>> >>>> Regards, >>>> Alon Bar-Lev. >>>> >>>> [1] http://resources.ovirt.org/releases/stable/ >>>> >>> >>> >> >> >> -- >> David Caro >> >> Red Hat S.L. >> Continuous Integration Engineer - EMEA ENG Virtualization R&D >> >> Email: dcaro@redhat.com >> Web: www.redhat.com >> RHT Global #: 82-62605 >> >>

-- David Caro

Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605

-- David Caro

Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605

-- David Caro

Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605

-- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --sgcf4aCB1pRufHv0vxXe0rmc66jEnh2iX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJS16LKAAoJEEBxx+HSYmnD8UcH/RHeR+blspx2Sgst5g5T20e9 z9pzH5Hg8OtRWM0m3i4PKZSZV7USl4kL5iJhydm6RDHDnn6HnYXF7JUal7DXcF3U TfWYmA/UjWHsih3dbgyCYPnxve5tr0qIM3wxJC5PIZIAfCwhIIZAzoN7Y1cAF+lu 1/AIfVW1SbLcCW4vrkKkCYBQWAZOmbgsbNyu5cvGIr+CEL8dirjBZvJw9a6bSXQS kfRysP8KIAmGhBwmM22HsJUJxy1E/zXZwqTyEgKPRxJFjvh18QrChPqNCerirtIn J5EqOxm6CcUmNwy04ztaBRY/fJer6fiGgl6tjIx27UERWSRzPErU9WszhWM/LKw= =3wcp -----END PGP SIGNATURE----- --sgcf4aCB1pRufHv0vxXe0rmc66jEnh2iX--

On 01/16/2014 01:49 PM, Sandro Bonazzola wrote:

Il 16/01/2014 10:13, David Caro ha scritto:

...

El jue 16 ene 2014 01:39:50 CET, Alon Bar-Lev escribió:

...

I won't argue more, obviously, you do not understand the point of distributed management.

Thanks Alon, always so useful.

...

But just think why don't we build large monolithic software.

Anyone thinks the same way Alon does? If so, can anyone explain me he's position? (As it seems he's not willing to do so)

Also any other opinions? Other Ideas?

IMHO we should keep our repositories as our downstream distro do.

For releases: releases/Fedora/19/3.3.0 releases/Fedora/19/3.3.1 releases/Fedora/19/3.3.2 releases/Fedora/19/3.3.3 releases/Fedora/20/3.4.0

doesn't our upgrade process inside a minor version requires the repo to have both new and old versions of the rpm?

.... and updates/19/ updates/20/

for all other packages which are not tied to ovirt release cycle.

I would like also that packages handled downstream as vdsm, -sdk-python and others would be removed from our upstream repository since they're handled downstream. on new z-stream release ovirt-release will be bumped yum update from releases/Fedora/19/3.4.0 will add 3.4.1 as new enabled repository yum update from releases/Fedora/19/3.4.1 will remove 3.4.0 and add 3.4.2 and conflict with any <= 3.4.0 yum update from releases/Fedora/19/3.4.2 will remove 3.4.1 and add 3.4.2 and conflict with any <= 3.4.1 and so on.

while otopi, log-collector and so on can safely be updated along all 3.4.z cycle.

...

...

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

...

From: "David Caro" <dcaroest@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "infra" <infra@ovirt.org>, "Kiril Nesenko" <kiril@redhat.com> Sent: Thursday, January 16, 2014 2:35:16 AM Subject: Re: release repo structure and 3.3.2

El jue 16 ene 2014 01:04:33 CET, Alon Bar-Lev escribió:

...

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

...

From: "David Caro" <dcaroest@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "infra" <infra@ovirt.org>, "Kiril Nesenko" <kiril@redhat.com> Sent: Thursday, January 16, 2014 1:58:08 AM Subject: Re: release repo structure and 3.3.2

El mié 15 ene 2014 19:04:04 CET, Alon Bar-Lev escribió: > > > ----- Original Message ----- >> From: "David Caro" <dcaroest@redhat.com> >> To: "Alon Bar-Lev" <alonbl@redhat.com> >> Cc: "Sandro Bonazzola" <sbonazzo@redhat.com>, "infra" <infra@ovirt.org>, >> "Kiril Nesenko" <kiril@redhat.com> >> Sent: Wednesday, January 15, 2014 5:47:59 PM >> Subject: Re: release repo structure and 3.3.2 >> >> El mié 15 ene 2014 16:30:00 CET, Alon Bar-Lev escribió: >>> >>> >>> ----- Original Message ----- >>>> From: "David Caro" <dcaroest@redhat.com> >>>> To: "Sandro Bonazzola" <sbonazzo@redhat.com>, "Alon Bar-Lev" >>>> <alonbl@redhat.com>, "infra" <infra@ovirt.org> >>>> Cc: "Kiril Nesenko" <kiril@redhat.com> >>>> Sent: Wednesday, January 15, 2014 5:26:32 PM >>>> Subject: Re: release repo structure and 3.3.2 >>>> >>>> El 07/01/14 15:31, Sandro Bonazzola escribió: >>>>> Il 01/01/2014 10:42, Alon Bar-Lev ha scritto: >>>>>> Hi, >>>>>> >>>>>> For some reason there 3.3.2 z-stream was released in its own >>>>>> repository >>>>>> so >>>>>> people that are subscribed to stable[1] did not get it. >>>>> >>>>> Why not? >>>>> stable release had ovirt-release-10 which enabled both stable and >>>>> 3.3.2 >>>>> repository by yum updating it. >>>>> >>>>>> >>>>>> There is no much sense in releasing fix release that people do not >>>>>> get >>>>>> in >>>>>> simple "yum update". >>>>>> >>>>>> Also the following is now broken of most packages' spec: >>>>>> Source0: >>>>>> http://ovirt.org/releases/stable/src/@PACKAGE_NAME@-@PACKAGE_VERSION@.tar.gz >>>>>> >>>>>> For each minor we should have rolling repository, to reduce noise >>>>>> and >>>>>> provide service. >>>>>> >>>>>> All released tarballs (sources) should be stored at fixed location >>>>>> to >>>>>> allow distro specific code to fetch, the location must be synced >>>>>> with >>>>>> what we publish. >>>>>> >>>>>> Immediate action is to move the 3.3.2 content into the stable >>>>>> directory. >>>>> >>>>> So previous request of having each release in its own repository has >>>>> been >>>>> retired? >>>>> Or is it combined? >>>>> Do we want stable to be a rolling repository and have also a >>>>> repository >>>>> for >>>>> each version? >>>>> I'm not against having rolling packages in just one stable >>>>> repository, >>>>> I >>>>> just want to understand what is the desired structure of the >>>>> repositories. >>>> >>>> I am, having a stable repository with rolling rpms is a lot more hard >>>> to >>>> manage >>>> and maintain than having separated individual complete repos. >>>> >>>> Because what we are actually delivering is not a specific rpm, but the >>>> whole >>>> set, that is, one repository with the set of rpms that were tested >>>> together >>>> and >>>> validated. If at any point you want to mix them, you still can adding >>>> the >>>> other >>>> repos. >>>> >>>> For updates just updating the directory where the 'stable' link points >>>> gets >>>> it done. >>>> >>>> For rollbacks you'll have to configure the old repo. That is not as >>>> annoying >>>> as >>>> it might seem, because when you enable the stable repo, you want to >>>> have >>>> the >>>> stable version, that changes with time. If you want to rollback to a >>>> previous >>>> version then just use that versions specific repo. At much we can >>>> provide >>>> a >>>> link >>>> like 'previous_stable' so if you want to rollback to the previous >>>> version >>>> you >>>> can use --enablerepo=previous_version easily, but if you want to keep >>>> using >>>> that, you should point directly to the specific version you want tot >>>> use. >>>> >>>> Creating a new repository using is almost as cheap (on hard disk >>>> space) >>>> as >>>> having a rolling repository, if you use hard links, so we can create >>>> lot's >>>> of >>>> them, specially for small changes from one to another. >>>> >>>> The only drawback that I see is when you have to release a minor >>>> change >>>> in >>>> one >>>> the the rpms, for example, to fix a critical bug, the repo will not >>>> include >>>> the >>>> old package, but I'm not sure if that's really a drawback... if you >>>> really >>>> need >>>> that package without the critical fix (you should not) you can have it >>>> changing >>>> to that specific repository. The internal naming of the repos does not >>>> really >>>> matter, having to point to the repo 3.3.3-beta.2 to get the second >>>> 'respin' >>>> of >>>> the 3.3.3 beta repo is not a big issue I think. >>>> >>>> The advantages are many, the most importants I see: >>>> - Easy management: >>>> * no need to go version hunting in the repo to remove/add rpms >>>> * you should never get a repo with version combinations that are >>>> not >>>> tested >>>> * it's a lot easier to get rid of old repos, and to move them >>>> around >>>> as >>>> they >>>> are independent >>>> * no broken links, right now stable repo is full of links to other >>>> repos, >>>> so >>>> removing those repos leave the links broken, you have to go >>>> checking >>>> if >>>> someone links to them (or their internal directories) if you have >>>> to >>>> clean >>>> up old versions >>>> - Testing, it's a lot easier to reproduce any error found, as you can >>>> just use the same repo and you'll get the same version set. >>>> >>>> What do you think? >>> >> >>> And you do not allow quick fix of issues found in various of packages. >> Why not? You can create a new repo based in the previous one that >> includes the fixed packages. It's cheap! > > who is you? In this case you is the person/process/chimpanzee that is in charge of publishing the fixed packages to the correct environment

> how do I push fix to users for z-stream of packages as otopi, > ovirt-host-deploy, log collector and such? Exactly the same way you do it for engine or vdsm

> why is these components' release cycle should be at same schedule of > ovirt-engine which is heavy and slow? It should not.

> >>> >>> Although there is /some/ sense in syncing minor releases, I do not see >>> any >>> reason of syncing z-stream. >>> >> >>> I think that you do not trust individual maintainer to provide >>> z-streams. >>> >>> A change in z-stream should not be exposed (unless is fixing) an >>> external >>> interface. >> >> I don't think it should be hidden neither, just make clear that those >> are not builds to be used widely, maybe just putting it under another >> directory (not releases). Where only promoted repos can go (meaning, >> not everyone can put repos there). >> For example: >> repos/releases -> for repos that have been tested and we want to publish >> repos/testing -> for any temporary generated repo, that is not fully >> tested and not ready for be used widely >> > > why not released? only because engine is slow? I do not understand. I don't even understand your question. We got lost at some point. I'll try to explain a little more what I said before, maybe that will clarify the issue to you. You said that a change in z-stream should not be exposed, for that I understand for that that a package that is meant to go to a z-stream should not be exposed to the general public. I think that it should, but it must be clear to the public that it's not yet ready (I suppose that's the reason you don't want it public), so they use it at their own risk. And separating the repos into two seems a good wat for making that clear (another one is adding a suffix to the repo name for example).

> >> That way you make sure that if anyone is using a repo that is not fully >> tested, is because he wants to, but you don't forbid it. > > why do you think that someone is releasing untested packages? I do not think that someone is releasing untested packages. That sentence comes from the hypothetical situation where a repository that is not meant to be used by the general public (I said untested, but it could be for any other reason) is made public using a different url than the repos that are meant to be widely used.

Part of the advantages of that system is the ease to run tests on specific version sets (repos). That we do not do right now (at least *upstream*) but I think would be done in the near future.

I will try to explain again.

There is no actual relationship between packages, these could have been provided asynchronous by multiple sources and maintainers regardless of the ovrit project, just like libvirt or sanlock or any other 10000 dependencies we have outside of the scope of the project.

That's not true, the relation is that they are provided by the same repository and that they are maintained by the same community. Yes, they could have been provided by multiple sources and maintainers, but they were not.

...

Trying to control the release cycle only because we have two fat components is something that should be avoided. The model I exposed does not care if you create a new repository each hour changing just one package or you create the repository on time a year. What it's true is that it will be recreated when ANY (one or more) of the packages included changes.

...

So far we have successfully released packages async with no regressions nor issues, and quickly solved user issues. There is absolutely no reason to stop this offering.

Yes, that in the last weeks sandro and me (mostly me) spent more than two days trying to create a couple releases with the old process. It's hard to maintain and I personally prefer focusing on another tasks than searching rpm versions and trying to figure out what can be deleted/moved and what can't. A proved way to improve things is to change them, try new ways, if you do not change you are waiting for the environment to do so, and that's usually really hard to achieve. Nothing suggests that adopting the process that I explained will affect the user experience substantially (if think otherwise, please elaborate).

...

...

> >>> >>> Alon >>> >>>> >>>>> >>>>>> Regards, >>>>>> Alon Bar-Lev. >>>>>> >>>>>> [1] http://resources.ovirt.org/releases/stable/ >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> David Caro >>>> >>>> Red Hat S.L. >>>> Continuous Integration Engineer - EMEA ENG Virtualization R&D >>>> >>>> Email: dcaro@redhat.com >>>> Web: www.redhat.com >>>> RHT Global #: 82-62605 >>>> >>>> >> >> >> >> -- >> David Caro >> >> Red Hat S.L. >> Continuous Integration Engineer - EMEA ENG Virtualization R&D >> >> Email: dcaro@redhat.com >> Web: www.redhat.com >> RHT Global #: 82-62605 >> >>

-- David Caro

Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605

-- David Caro

Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605

-- David Caro

Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D

Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605

Hi Guys, I do not understand why it is so complicated, and why we need to re-invent the wheel. Downstream (rhel) considerations are not applied to upstream, as it can have its own release cycle, cherry-pick whatever it likes. z-stream by nature is per component, as interface is not broken. The decision when to release z-stream of a component is up to component maintainer. The release cycle of each component should be independent at least for its z-stream component. If we have an issue with one component which is unmaintainable (ovirt-engine), we can have separate repos for this one to be managed by different policy (non rolling z-stream). However, as the decision of when to put a component into stable repo is up to maintainer anyway, there is no sense in splitting it either. So once again, I suggest that once a component is released it is moved to stable repository. If there is a package that cannot survive that (such ovirt-engine and maybe vdsm) with issues of backward compatibility and such we can have another repo per *MINOR* version to handle these, the decision of pushing z-stream into that repository is up to maintainer. Regards, Alon