Package building and build process
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6UFBx7CdX7wgDEfkcHxPf8MQuLU2KO8Fu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi! Lately we had some issues when trying to build some of the projects, and = we wanted to start a discussion to clarify what do we want and how to get th= ere. We can split the thread if it gets too large for all the subjects. The main points to discuss: * How the source tarballs should be built =B7 Should we use a jenkins job for it, so the maintainer just download= s the tarball from it =B7 Should we force the maintainer to build it and supply the tarball h= imself =B7 Should we allow both * Separate source release from binary release * Which tools to use to build the rpms =B7 plain rpmbuild =B7 Mock =B7 Docker =B7 copr =B7 Open Build System =B7 koji * How to organize the rpm/tar build jobs =B7 One job for all the projects =B7 One job per-project PD. Opened an etherpad to keep the points http://etherpad.ovirt.org/p/build_discussion --=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 --6UFBx7CdX7wgDEfkcHxPf8MQuLU2KO8Fu 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 iQEcBAEBAgAGBQJTZ7DJAAoJEEBxx+HSYmnDCb4IAIUN3VbtUXNnVpNIf0tgprTM gY70zWUD5H5djyuIh0pNn57vUWKo8kiS7oJM4k3ixGevIBeA1yYI9YprVSD6JvLw Vu1V1pZQwVxu2Z7WBxwx6+Qa28QvwznIlRX627+tixrtDnNgFDfx321I8H1hCcLY uNjOjC+E4rFa7i3rpqB3Klqf/o1qXE6xbJt8dYEwMOA+Ykoso94CAP4VyXCnAsU6 RYudI/lHsS3vEXwkqmONy08E1cExyJzb0E8jm53oq8XdgAtELrXdgslN4vie1Qh/ etMxLPPYlTLN5/SpaCSfg/jwx2D2SJLOyv9ZDWDnTh8k41hka7tsU/6jqByIzV8= =OuNM -----END PGP SIGNATURE----- --6UFBx7CdX7wgDEfkcHxPf8MQuLU2KO8Fu--
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "infra" <infra@ovirt.org> Sent: Monday, May 5, 2014 6:39:53 PM Subject: Package building and build process
Hi!
Lately we had some issues when trying to build some of the projects, and we wanted to start a discussion to clarify what do we want and how to get there.
We can split the thread if it gets too large for all the subjects.
The main points to discuss:
* How the source tarballs should be built · Should we use a jenkins job for it, so the maintainer just downloads the tarball from it · Should we force the maintainer to build it and supply the tarball himself · Should we allow both
Not sure why you manage this discussion. You just forgot to mention that up until now it worked perfectly ok, we had a job to build releases out of tarballs, and all worked perfectly. It was broken when you decided not to install certain dependencies on build slaves. Anyway... This is up to maintainer to decide. Build infrastructure should be able to get upstream tarball (any upstream not just ovirt) and produce binaries for all our supported platforms as a service, just like koji, brew or any downstream service. The root resource of open source is the source tarball, this is the release not the binary. People here at ovirt tend to confuse what open source is.
* Separate source release from binary release
* Which tools to use to build the rpms · plain rpmbuild · Mock · Docker · copr · Open Build System · koji
Once upstream releases source tarball, this is not important. This is the entire idea of open *SOURCE*.
* How to organize the rpm/tar build jobs · One job for all the projects · One job per-project
If we cannot provide single job for generic tarball build, we have a huge problem. I worked very hard with all maintainers (except vdsm) to be able to achieve the standard sequence of: # rpmbuild -tb <tarball> Regards, Alon Bar-Lev.
PD. Opened an etherpad to keep the points http://etherpad.ovirt.org/p/build_discussion -- 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
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
=20 =20 ----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "infra" <infra@ovirt.org> Sent: Monday, May 5, 2014 6:39:53 PM Subject: Package building and build process
Hi!
Lately we had some issues when trying to build some of the projects, a= nd we wanted to start a discussion to clarify what do we want and how to get=
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ut5KeQuHDK9anwIkd85SuJEOGNdVSwa9b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/05/2014 05:51 PM, Alon Bar-Lev wrote: there.
We can split the thread if it gets too large for all the subjects.
The main points to discuss:
* How the source tarballs should be built =C2=B7 Should we use a jenkins job for it, so the maintainer just do=
wnloads the
tarball from it =C2=B7 Should we force the maintainer to build it and supply the tar=
ball himself
=C2=B7 Should we allow both =20 Not sure why you manage this discussion. You just forgot to mention that up until now it worked perfectly ok, we= had a job to build releases out of tarballs, and all worked perfectly. It was broken when you decided not to install certain dependencies on b= uild slaves.
Arising from different version of some projects requiring different versi= on of different packages and different test requiring different sources for the= same packages (testing against nightly, stable, pep8 latest, pep8 epel, ...) w= e had to introduce some job isolation, and reserving one slave for each job tha= t is running became unproductive and hard to maintain (at first, we had some s= laves for each project, then started installing and removing packages on each j= ob, then not only installing and removing packages but also repositories, iso= lating the build on the same slave became a necessity).
=20 Anyway... =20 This is up to maintainer to decide.
It's up to the CI/infra/release team to provide the platform to build the= projects for the maintainers to use.
Build infrastructure should be able to get upstream tarball (any upstre= am not just ovirt) and produce binaries for all our supported platforms a= s a service, just like koji, brew or any downstream service. The root resource of open source is the source tarball, this is the rel= ease not the binary. That's what the next point is about.
People here at ovirt tend to confuse what open source is. =20
* Separate source release from binary release
* Which tools to use to build the rpms =C2=B7 plain rpmbuild =C2=B7 Mock =C2=B7 Docker =C2=B7 copr =C2=B7 Open Build System =C2=B7 koji
=20 Once upstream releases source tarball, this is not important. This is the entire idea of open *SOURCE*. It might not be important to you, but we want to provide the easiest way = for the users to use oVirt, not only for someone to build it, having a binary rel= ease for the major platforms helps TREMENDOUSLY on getting users to use the pr= oduct.
=20
* How to organize the rpm/tar build jobs =C2=B7 One job for all the projects =C2=B7 One job per-project =20 If we cannot provide single job for generic tarball build, we have a hu= ge problem. I don't agree.
=20 I worked very hard with all maintainers (except vdsm) to be able to ach= ieve the standard sequence of: =20 # rpmbuild -tb <tarball>
You are not taking into account all the dependencies that rpmbuild -tb <t= arball> has, each project has it's own, and they are incompatible between project= s and between versions. And not just building the rpms, building the tarballs a= lso have some requirements that must be met. So building a package is not jus= t rpmbuild, but setup the repos, install packages, then rpmbuild, then clea= nup packages and restore repos.
=20 Regards, Alon Bar-Lev. =20
PD. Opened an etherpad to keep the points http://etherpad.ovirt.org/p/build_discussion -- 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
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
--=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 --Ut5KeQuHDK9anwIkd85SuJEOGNdVSwa9b 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 iQEcBAEBAgAGBQJTZ7f3AAoJEEBxx+HSYmnDku8H/0fsG5LEkLYCc8X0j/XPWW/u X7rdoZuuLGaXjs966YmeM1sQD3VjtAg35qo1EXr/GdQesft0Ysn8zAzohjkrf+YH A/iX+QzC/N1M5mGYWgKTxCDDIdsxraQiLAQ14ykDhzAniF8UdGnmrRTdmUxBCbyh kZi7yMeD79iEJR1YoZY5oFY6CsBAdfeyZW6z3Gj7+deDhgOh9AtrsYVKvdvDmQVy 81WwAW5PWuMFPS1NuM7KrToaoiq1bsLO0Yj/8QdPJaaJ3BoybESchKsUr8f6SMXi jaKVXzX6axvZIqD4W+RKa1VPzGSj78edxjUlxvJITJz4j8OHL91l5GG11O1ztyU= =JVm7 -----END PGP SIGNATURE----- --Ut5KeQuHDK9anwIkd85SuJEOGNdVSwa9b--
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "infra" <infra@ovirt.org> Sent: Monday, May 5, 2014 7:10:31 PM Subject: Re: Package building and build process
On 05/05/2014 05:51 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "infra" <infra@ovirt.org> Sent: Monday, May 5, 2014 6:39:53 PM Subject: Package building and build process
Hi!
Lately we had some issues when trying to build some of the projects, and we wanted to start a discussion to clarify what do we want and how to get there.
We can split the thread if it gets too large for all the subjects.
The main points to discuss:
* How the source tarballs should be built · Should we use a jenkins job for it, so the maintainer just downloads the tarball from it · Should we force the maintainer to build it and supply the tarball himself · Should we allow both
Not sure why you manage this discussion. You just forgot to mention that up until now it worked perfectly ok, we had a job to build releases out of tarballs, and all worked perfectly. It was broken when you decided not to install certain dependencies on build slaves.
Arising from different version of some projects requiring different version of different packages and different test requiring different sources for the same packages (testing against nightly, stable, pep8 latest, pep8 epel, ...) we had to introduce some job isolation, and reserving one slave for each job that is running became unproductive and hard to maintain (at first, we had some slaves for each project, then started installing and removing packages on each job, then not only installing and removing packages but also repositories, isolating the build on the same slave became a necessity).
Anyway...
This is up to maintainer to decide.
It's up to the CI/infra/release team to provide the platform to build the projects for the maintainers to use.
As a service to the group.
Build infrastructure should be able to get upstream tarball (any upstream not just ovirt) and produce binaries for all our supported platforms as a service, just like koji, brew or any downstream service. The root resource of open source is the source tarball, this is the release not the binary. That's what the next point is about.
People here at ovirt tend to confuse what open source is.
* Separate source release from binary release
* Which tools to use to build the rpms · plain rpmbuild · Mock · Docker · copr · Open Build System · koji
Once upstream releases source tarball, this is not important. This is the entire idea of open *SOURCE*. It might not be important to you, but we want to provide the easiest way for the users to use oVirt, not only for someone to build it, having a binary release for the major platforms helps TREMENDOUSLY on getting users to use the product.
Once again... and again... and again.... The release is the source tarball. We provide the service of providing binaries as well. This is fine, this is a service.
* How to organize the rpm/tar build jobs · One job for all the projects · One job per-project
If we cannot provide single job for generic tarball build, we have a huge problem.
I don't agree.
You do not need to agree, you should provide it as a service.
I worked very hard with all maintainers (except vdsm) to be able to achieve the standard sequence of:
# rpmbuild -tb <tarball>
You are not taking into account all the dependencies that rpmbuild -tb <tarball> has, each project has it's own, and they are incompatible between projects and between versions. And not just building the rpms, building the tarballs also have some requirements that must be met. So building a package is not just rpmbuild, but setup the repos, install packages, then rpmbuild, then cleanup packages and restore repos.
rpmbuild -ts <tarball> yum-builddep <srpm> solves this as well, adding optional repositories can be a parameter to the job. all was already done nothing to reinvent.
Regards, Alon Bar-Lev.
PD. Opened an etherpad to keep the points http://etherpad.ovirt.org/p/build_discussion -- 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
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- 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
=20 =20 ----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "infra" <infra@ovirt.org> Sent: Monday, May 5, 2014 7:10:31 PM Subject: Re: Package building and build process
On 05/05/2014 05:51 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "David Caro" <dcaroest@redhat.com> To: "infra" <infra@ovirt.org> Sent: Monday, May 5, 2014 6:39:53 PM Subject: Package building and build process
Hi!
Lately we had some issues when trying to build some of the projects,=
and
we wanted to start a discussion to clarify what do we want and how to g= et there.
We can split the thread if it gets too large for all the subjects.
The main points to discuss:
* How the source tarballs should be built =C2=B7 Should we use a jenkins job for it, so the maintainer just = downloads the tarball from it =C2=B7 Should we force the maintainer to build it and supply the t= arball himself =C2=B7 Should we allow both
Not sure why you manage this discussion. You just forgot to mention that up until now it worked perfectly ok, = we had a job to build releases out of tarballs, and all worked perfectly. It was broken when you decided not to install certain dependencies on= build slaves.
Arising from different version of some projects requiring different ve= rsion of different packages and different test requiring different sources for =
same packages (testing against nightly, stable, pep8 latest, pep8 epel, ...= ) we had to introduce some job isolation, and reserving one slave for each job =
running became unproductive and hard to maintain (at first, we had som= e slaves for each project, then started installing and removing packages on eac= h job, then not only installing and removing packages but also repositories, isolating the build on the same slave became a necessity).
Anyway...
This is up to maintainer to decide.
It's up to the CI/infra/release team to provide the platform to build =
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oOWjjvxotEwtajEGIaiDpMrF0lf0pFnKH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/05/2014 06:26 PM, Alon Bar-Lev wrote: the that is the
projects for the maintainers to use. =20 As a service to the group.
Yes, as a service to the group and ultimately to the project I'm part of = the people that decides how to manage and provide that infrastructure.
=20
Build infrastructure should be able to get upstream tarball (any upst=
ream
not just ovirt) and produce binaries for all our supported platforms = as a service, just like koji, brew or any downstream service. The root resource of open source is the source tarball, this is the r= elease not the binary. That's what the next point is about.
People here at ovirt tend to confuse what open source is.
* Separate source release from binary release
* Which tools to use to build the rpms =C2=B7 plain rpmbuild =C2=B7 Mock =C2=B7 Docker =C2=B7 copr =C2=B7 Open Build System =C2=B7 koji
Once upstream releases source tarball, this is not important. This is the entire idea of open *SOURCE*. It might not be important to you, but we want to provide the easiest w= ay for the users to use oVirt, not only for someone to build it, having a binary = release for the major platforms helps TREMENDOUSLY on getting users to use the=
product. =20 Once again... and again... and again.... =20 The release is the source tarball. I already acked this.
We provide the service of providing binaries as well. This is fine, this is a service. =20
* How to organize the rpm/tar build jobs =C2=B7 One job for all the projects =C2=B7 One job per-project
If we cannot provide single job for generic tarball build, we have a =
problem. I don't agree. =20 You do not need to agree, you should provide it as a service. Yes, I need to agree, as I've been appointed by the group as part of the decision making process that has responsibility over that service, you ar= e not. And as such you haven't earned the right to tell anyone in this team what=
huge they should and what they should not do, you are welcome to share your opinion= , but don't expect anyone to follow your orders.
=20
I worked very hard with all maintainers (except vdsm) to be able to a=
chieve
the standard sequence of:
# rpmbuild -tb <tarball>
You are not taking into account all the dependencies that rpmbuild -tb=
<tarball> has, each project has it's own, and they are incompatible between proj= ects and between versions. And not just building the rpms, building the tarball= s also have some requirements that must be met. So building a package is not = just rpmbuild, but setup the repos, install packages, then rpmbuild, then c= leanup packages and restore repos. =20 rpmbuild -ts <tarball> yum-builddep <srpm> =20 solves this as well, adding optional repositories can be a parameter to= the job.
I did not say that it was not doable, only that we might want to replicat= e it per-project for the sake of organization and easy management.
=20 all was already done nothing to reinvent. =20
Regards, Alon Bar-Lev.
PD. Opened an etherpad to keep the points http://etherpad.ovirt.org/p/build_discussion -- 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
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- 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
--=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 --oOWjjvxotEwtajEGIaiDpMrF0lf0pFnKH 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 iQEcBAEBAgAGBQJTZ8FiAAoJEEBxx+HSYmnDDx0H/R5S17q2YSZ9bbggjHwM08vt wu4m5dE+05dGOyWV5ZQP+M4xGey3LAf85j2KXelOhqKPYDUZClYMuyiEbywG1cw1 GQzUXNVCC8UY9ZryGND/84r8wp+6L5x7Fhyodc/7sr1QKtlxo3aBmYTss7pQX9q7 So9prfjdHaMAhHt9MqaOx4y/KzGFJbUYb9S/EiCaW4OXvwpIEwrLgzwALha8aUCd vTHWItQSU+8foCEDz1RPwQ34++CxwnbXC7ccpDY59OJ3fiz43Hia9xV2gBR+B7jE DJN9TpuGAMaXC5bpa0abanFxC8FCG6nI7j00rsTHz+ikh+rnEeMrbzgyEpxReNQ= =7PVQ -----END PGP SIGNATURE----- --oOWjjvxotEwtajEGIaiDpMrF0lf0pFnKH--
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Wo19qiqIGVxkOaVEgPPs7nOPlwUAGeqca
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'll add some pros and cons I see for each point, and others someone (I c=
an't
see who, please qritw your nick there) wrote in the pad:
On Mon 05 May 2014 05:39:53 PM CEST, David Caro wrote:
> * How the source tarballs should be built
> =C2=B7 Should we use a jenkins job for it, so the maintainer just dow=
nloads the
> tarball from it
+ reproducible
+ automatizable
- extra jenkins job load
> =C2=B7 Should we force the maintainer to build it and supply the tarb=
all himself
+ The maintainer has full control on how it's generated
- Might introduce human errors
- extra maintainer work
- non-automatizable
- makes it hard to do nightlies (from the pad)
> =C2=B7 Should we allow both
same pluses as before
- extra work for everyone
- plus for confusion on how to do it for the maintainers
> * Separate source release from binary release
+ Logical separation from source and binary, as the source is our prima=
ry
deliverable
- To test the code you already need the binaries, no point on duplicati=
ng the
release effort
This is meant to separate our main deliverable (source code) from seconda=
ry one
(the binaries).
>
> * Which tools to use to build the rpms
> =C2=B7 plain rpmbuild
+ simple build process
- hard setup/cleanup as it needs to install dependencies from diffe=
rent
sources and then clean them up
- needs the slave to be blocked as it needs to install/remove
dependencies from different repos
- only rpm
> =C2=B7 Mock
+ stable
+ each build is independent from the system
+ same build system as koji
- uses quite a lot of space
- it's not straight-forward to use
- only rpm
> =C2=B7 Docker
+ Very simple to use
+ moderate disk usage
+ each build is independent from the system
+ not only rpm
+ it's getting a lot of focus (from RedHat and a lot
of others)
- not so stable
> =C2=B7 copr
+/- external service
+ simple to use (simple api/ui)
- only rpm
- quite new
> =C2=B7 Open Build System
+/- external service
+ not only rpm
- complex api/ui
> =C2=B7 koji
+/- external service
+ official fedora build system
- only rpm
- there were some issues that prevented us from already building th=
ere,
anyone knows more details?
>
>
> * How to organize the rpm/tar build jobs
> =C2=B7 One job for all the projects
+ less confusion when building, one place for everything
- really hard to select a specific project artifacts
- really hard to automate
- really hard to filter per-project builds
> =C2=B7 One job per-project
+ easy to filter per-project and see project status
+ easy to automate processes to get artifacts from it
+ easy to customize per-project dependencies
- might create confusion on where to build your tarball
>
>
>
> PD. Opened an etherpad to keep the points
> http://etherpad.ovirt.org/p/build_discussion
--=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
--Wo19qiqIGVxkOaVEgPPs7nOPlwUAGeqca
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
iQEcBAEBAgAGBQJTZ7oUAAoJEEBxx+HSYmnDI4AH/136ZcnkHittSPu1XvHRZcMs
X0fwFFhCRpMyaHaNzNog7CPP2fh88oOqkXTs2Ha8L2V8+Sx5Gdc2kvDbnmVKKDfo
AFEOkPfvzJHTQ7mViz7yGufW3FWVZqutYIDNe734yvuv5ZEQt0fI7LPGK5hIBejZ
Hnd7pL9NAqdKtU5Pj6htTVGZKfg91TQYSqvqGwW7pFrxV69UjtfP8XCIIM3vyQR2
43ekJ6s8W5Tvsa0ZZNSDa5vKiMiCP8XmDMlM/82t+eA1gbWT9EpZouJoaTg7bp2z
gDvjE/ekgzZOo+YW/EJfiRtzLTYX3PTHzCnSHfoxogDG57GoYlRbjzo2WPAMWXE=
=kRSm
-----END PGP SIGNATURE-----
--Wo19qiqIGVxkOaVEgPPs7nOPlwUAGeqca--
participants (2)
-
Alon Bar-Lev -
David Caro