I see there are 2 RHEL 6.2 slaves added to Jenkins and I see they are doing something with the engine? What are they actually doing since I don't see any artifacts left over? How hard would it be to tweak the existing ones to create .rpms? Thanks Robert
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: "infra" <infra@ovirt.org> Sent: Thursday, July 12, 2012 5:44:44 PM Subject: Jenkins and RHEL 6.2
I see there are 2 RHEL 6.2 slaves added to Jenkins and I see they are doing something with the engine? What are they actually doing since I don't see any artifacts left over? How hard would it be to tweak the existing ones to create .rpms?
currently they are used for running mvn jobs like unit tests/find bugs. you mean use them to create RPMs for ovirt-engine? supposing make rpm will work for that, all we'll need is to make sure they have the right rpm build packages installed (rpmbuild, make,autoconf,etc....)
Thanks Robert _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
On Thu, 2012-07-12 at 10:59 -0400, Eyal Edri wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: "infra" <infra@ovirt.org> Sent: Thursday, July 12, 2012 5:44:44 PM Subject: Jenkins and RHEL 6.2
I see there are 2 RHEL 6.2 slaves added to Jenkins and I see they are doing something with the engine? What are they actually doing since I don't see any artifacts left over? How hard would it be to tweak the existing ones to create .rpms?
currently they are used for running mvn jobs like unit tests/find bugs.
you mean use them to create RPMs for ovirt-engine? supposing make rpm will work for that, all we'll need is to make sure they have the right rpm build packages installed (rpmbuild, make,autoconf,etc....)
If we want to do that, we should go down a slightly different path. Each project should have a job that makes the source rpm and tarball. Then separate jobs on each of the platforms (fedora, RHEL, ubuntu, etc...) that will take the srpm and/or tarball and generate packages for the distro. Mike
Thanks Robert _______________________________________________ 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
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: "infra" <infra@ovirt.org> Sent: Thursday, July 12, 2012 5:44:44 PM Subject: Jenkins and RHEL 6.2
I see there are 2 RHEL 6.2 slaves added to Jenkins and I see they are doing something with the engine? What are they actually doing since I don't see any artifacts left over? How hard would it be to tweak the existing ones to create .rpms?
currently they are used for running mvn jobs like unit tests/find bugs.
you mean use them to create RPMs for ovirt-engine? supposing make rpm will work for that, all we'll need is to make sure they have the right rpm build packages installed (rpmbuild, make,autoconf,etc....) If we want to do that, we should go down a slightly different path. Each project should have a job that makes the source rpm and tarball. Then separate jobs on each of the platforms (fedora, RHEL, ubuntu, etc...) that will take the srpm and/or tarball and generate packages for
On Thu, 2012-07-12 at 10:59 -0400, Eyal Edri wrote: the distro.
Mike Well all the packages are built from a tar file but SPRM wont work for Debian based systems. On my testing system creating the .tar.gz file takes like 10 seconds. But having an updated tar.gz file on every master commit could be useful. Not sure how much having a pre-done src tar is going to save in actual build time. Although having diff build
On 07/12/2012 11:48 AM, Mike Burns wrote: packages for each distro makes a lot of since. I am all about steps to make something happen. I can think of some steps we could go though to convert the process but at best it would be based on my basic knowledge you know the current build process and would be best for you to outline the steps to get the changes in place. What steps do you think are the best steps to getting the process changed up? Thanks Robert
Thanks Robert _______________________________________________ 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 Thu, 2012-07-12 at 23:30 -0400, Robert Middleswarth wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: "infra" <infra@ovirt.org> Sent: Thursday, July 12, 2012 5:44:44 PM Subject: Jenkins and RHEL 6.2
I see there are 2 RHEL 6.2 slaves added to Jenkins and I see they are doing something with the engine? What are they actually doing since I don't see any artifacts left over? How hard would it be to tweak the existing ones to create .rpms?
currently they are used for running mvn jobs like unit tests/find bugs.
you mean use them to create RPMs for ovirt-engine? supposing make rpm will work for that, all we'll need is to make sure they have the right rpm build packages installed (rpmbuild, make,autoconf,etc....) If we want to do that, we should go down a slightly different path. Each project should have a job that makes the source rpm and tarball. Then separate jobs on each of the platforms (fedora, RHEL, ubuntu, etc...) that will take the srpm and/or tarball and generate packages for
On Thu, 2012-07-12 at 10:59 -0400, Eyal Edri wrote: the distro.
Mike Well all the packages are built from a tar file but SPRM wont work for Debian based systems. On my testing system creating the .tar.gz file takes like 10 seconds. But having an updated tar.gz file on every master commit could be useful. Not sure how much having a pre-done src tar is going to save in actual build time. Although having diff build
On 07/12/2012 11:48 AM, Mike Burns wrote: packages for each distro makes a lot of since. I am all about steps to make something happen. I can think of some steps we could go though to convert the process but at best it would be based on my basic knowledge you know the current build process and would be best for you to outline the steps to get the changes in place. What steps do you think are the best steps to getting the process changed up?
So my thoughts in general on this (can be applied to any code based sub-project except node): Job 1: build source (done on latest fedora and/or rhel host) generates source tarball generates srpm exports both as artifacts Job 2: Build Fedora 17 RPMs takes srpm artifact from Job 1 uses mock to build F17 RPMs Job 3: Build EL6 RPMs takes srpm artifact from Job 1 uses mock to build EL6 RPMs Job 4-X: Build RPM for Distro XYZ takes either SRPM or tarball depending on distro build distro specific packages As for the code to do each job, I don't know all the ins and outs of building each individual component, but something like a make dist and/or a make srpm should provide the needed artifacts. I also don't know mock very well, but I'm pretty sure it's pretty straightforward for most packages. Potential problems that I see: 1. spec files will need massaging for el6 and f17 diffs 2. will need distro specific spec file equivalents for each distro we support 3. possible missing options to create srpm and src tarball ovirt-node: only really supported on fedora right now. We could possibly build packages for el6 and other distros that contain the fedora based iso, but not sure if that is really useful or not. As for an EL6 based image, that will take some work to figure out as well (and not sure if that's really a major driver at this point or not). Mike
Thanks Robert
Thanks Robert _______________________________________________ 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 07/12/2012 11:50 PM, Mike Burns wrote:
On Thu, 2012-07-12 at 23:30 -0400, Robert Middleswarth wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: "infra" <infra@ovirt.org> Sent: Thursday, July 12, 2012 5:44:44 PM Subject: Jenkins and RHEL 6.2
I see there are 2 RHEL 6.2 slaves added to Jenkins and I see they are doing something with the engine? What are they actually doing since I don't see any artifacts left over? How hard would it be to tweak the existing ones to create .rpms?
currently they are used for running mvn jobs like unit tests/find bugs.
you mean use them to create RPMs for ovirt-engine? supposing make rpm will work for that, all we'll need is to make sure they have the right rpm build packages installed (rpmbuild, make,autoconf,etc....) If we want to do that, we should go down a slightly different path. Each project should have a job that makes the source rpm and tarball. Then separate jobs on each of the platforms (fedora, RHEL, ubuntu, etc...) that will take the srpm and/or tarball and generate packages for
On Thu, 2012-07-12 at 10:59 -0400, Eyal Edri wrote: the distro.
Mike Well all the packages are built from a tar file but SPRM wont work for Debian based systems. On my testing system creating the .tar.gz file takes like 10 seconds. But having an updated tar.gz file on every master commit could be useful. Not sure how much having a pre-done src tar is going to save in actual build time. Although having diff build
On 07/12/2012 11:48 AM, Mike Burns wrote: packages for each distro makes a lot of since. I am all about steps to make something happen. I can think of some steps we could go though to convert the process but at best it would be based on my basic knowledge you know the current build process and would be best for you to outline the steps to get the changes in place. What steps do you think are the best steps to getting the process changed up? So my thoughts in general on this (can be applied to any code based sub-project except node):
Job 1: build source (done on latest fedora and/or rhel host) generates source tarball generates srpm Can 1 srpm file support Fedora 17, Fedora 18, and EL6? Or will the build process create 3 srpm files one for each rpm based distro? Still learning about rpm spec files been in the .deb world for that last 8 years. exports both as artifacts Job 2: Build Fedora 17 RPMs takes srpm artifact from Job 1 uses mock to build F17 RPMs
Job 3: Build EL6 RPMs takes srpm artifact from Job 1 uses mock to build EL6 RPMs Job 4-X: Build RPM for Distro XYZ takes either SRPM or tarball depending on distro build distro specific packages
As for the code to do each job, I don't know all the ins and outs of building each individual component, but something like a make dist and/or a make srpm should provide the needed artifacts.
I also don't know mock very well, but I'm pretty sure it's pretty straightforward for most packages.
Potential problems that I see:
1. spec files will need massaging for el6 and f17 diffs Can one spec file be used or will we need one for F17, F18, EL6? 2. will need distro specific spec file equivalents for each distro we support Yep. From what I can see of the format of the engine repo there shouldn't be any issue in just having debian packaging files in the repo and just pulling them out for the build process. 3. possible missing options to create srpm and src tarball
ovirt-node:
only really supported on fedora right now. We could possibly build packages for el6 and other distros that contain the fedora based iso, but not sure if that is really useful or not. EL6 builds would be nice not sure how many changes would be needed. Judging by the fact the current EL6 builds don't build nodes it is more
Job 2.5: Build Fedora 18 RPMs once Fedora starts beta testing? takes srpm artifact from Job 1 uses mock to build F17 RPMs then trivial.
As for an EL6 based image, that will take some work to figure out as well (and not sure if that's really a major driver at this point or not). If we are going to support EL6 it would be nice to have node builds for it. But time might better spent working on other projects.
Thanks Robert
Mike
Thanks Robert
Thanks Robert _______________________________________________ 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 Fri, 2012-07-13 at 00:40 -0400, Robert Middleswarth wrote:
On 07/12/2012 11:50 PM, Mike Burns wrote:
On Thu, 2012-07-12 at 23:30 -0400, Robert Middleswarth wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: "infra" <infra@ovirt.org> Sent: Thursday, July 12, 2012 5:44:44 PM Subject: Jenkins and RHEL 6.2
I see there are 2 RHEL 6.2 slaves added to Jenkins and I see they are doing something with the engine? What are they actually doing since I don't see any artifacts left over? How hard would it be to tweak the existing ones to create .rpms?
currently they are used for running mvn jobs like unit tests/find bugs.
you mean use them to create RPMs for ovirt-engine? supposing make rpm will work for that, all we'll need is to make sure they have the right rpm build packages installed (rpmbuild, make,autoconf,etc....) If we want to do that, we should go down a slightly different path. Each project should have a job that makes the source rpm and tarball. Then separate jobs on each of the platforms (fedora, RHEL, ubuntu, etc...) that will take the srpm and/or tarball and generate packages for
On Thu, 2012-07-12 at 10:59 -0400, Eyal Edri wrote: the distro.
Mike Well all the packages are built from a tar file but SPRM wont work for Debian based systems. On my testing system creating the .tar.gz file takes like 10 seconds. But having an updated tar.gz file on every master commit could be useful. Not sure how much having a pre-done src tar is going to save in actual build time. Although having diff build
On 07/12/2012 11:48 AM, Mike Burns wrote: packages for each distro makes a lot of since. I am all about steps to make something happen. I can think of some steps we could go though to convert the process but at best it would be based on my basic knowledge you know the current build process and would be best for you to outline the steps to get the changes in place. What steps do you think are the best steps to getting the process changed up? So my thoughts in general on this (can be applied to any code based sub-project except node):
Job 1: build source (done on latest fedora and/or rhel host) generates source tarball generates srpm Can 1 srpm file support Fedora 17, Fedora 18, and EL6? Or will the build process create 3 srpm files one for each rpm based distro? Still learning about rpm spec files been in the .deb world for that last 8 years.
In every case I've come across, yes.
exports both as artifacts Job 2: Build Fedora 17 RPMs takes srpm artifact from Job 1 uses mock to build F17 RPMs
Job 2.5: Build Fedora 18 RPMs once Fedora starts beta testing? takes srpm artifact from Job 1 uses mock to build F17 RPMs
Sure, but F18 RPMs. BTW, with mock, we might even be able to build F17, F18, F*, EL* rpms all on one server. All depends on the mock config files, and fedora has one for EL6, fedora 14-17 and rawhide (18)
Job 3: Build EL6 RPMs takes srpm artifact from Job 1 uses mock to build EL6 RPMs Job 4-X: Build RPM for Distro XYZ takes either SRPM or tarball depending on distro build distro specific packages
As for the code to do each job, I don't know all the ins and outs of building each individual component, but something like a make dist and/or a make srpm should provide the needed artifacts.
I also don't know mock very well, but I'm pretty sure it's pretty straightforward for most packages.
Potential problems that I see:
1. spec files will need massaging for el6 and f17 diffs Can one spec file be used or will we need one for F17, F18, EL6?
Yes, one spec is fine. Just need to have parts of it conditionalized for F17, F18, EL6...
2. will need distro specific spec file equivalents for each distro we support Yep. From what I can see of the format of the engine repo there shouldn't be any issue in just having debian packaging files in the repo and just pulling them out for the build process. 3. possible missing options to create srpm and src tarball
ovirt-node:
only really supported on fedora right now. We could possibly build packages for el6 and other distros that contain the fedora based iso, but not sure if that is really useful or not. EL6 builds would be nice not sure how many changes would be needed. Judging by the fact the current EL6 builds don't build nodes it is more then trivial.
There was some work done to support Centos in the past, so it might not be too bad. I'll have to look closer though.
As for an EL6 based image, that will take some work to figure out as well (and not sure if that's really a major driver at this point or not). If we are going to support EL6 it would be nice to have node builds for it. But time might better spent working on other projects.
Agreed, it's lower prio for node than other projects.
Thanks Robert
Mike
Thanks Robert
Thanks Robert _______________________________________________ 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 07/13/2012 12:54 AM, Mike Burns wrote:
On Fri, 2012-07-13 at 00:40 -0400, Robert Middleswarth wrote:
On 07/12/2012 11:50 PM, Mike Burns wrote:
On Thu, 2012-07-12 at 23:30 -0400, Robert Middleswarth wrote:
----- Original Message ----- > From: "Robert Middleswarth" <robert@middleswarth.net> > To: "infra" <infra@ovirt.org> > Sent: Thursday, July 12, 2012 5:44:44 PM > Subject: Jenkins and RHEL 6.2 > > I see there are 2 RHEL 6.2 slaves added to Jenkins and I see they are > doing something with the engine? What are they actually doing since > I > don't see any artifacts left over? How hard would it be to tweak the > existing ones to create .rpms? > currently they are used for running mvn jobs like unit tests/find bugs.
you mean use them to create RPMs for ovirt-engine? supposing make rpm will work for that, all we'll need is to make sure they have the right rpm build packages installed (rpmbuild, make,autoconf,etc....) If we want to do that, we should go down a slightly different path. Each project should have a job that makes the source rpm and tarball. Then separate jobs on each of the platforms (fedora, RHEL, ubuntu, etc...) that will take the srpm and/or tarball and generate packages for
On Thu, 2012-07-12 at 10:59 -0400, Eyal Edri wrote: the distro.
Mike Well all the packages are built from a tar file but SPRM wont work for Debian based systems. On my testing system creating the .tar.gz file takes like 10 seconds. But having an updated tar.gz file on every master commit could be useful. Not sure how much having a pre-done src tar is going to save in actual build time. Although having diff build
On 07/12/2012 11:48 AM, Mike Burns wrote: packages for each distro makes a lot of since. I am all about steps to make something happen. I can think of some steps we could go though to convert the process but at best it would be based on my basic knowledge you know the current build process and would be best for you to outline the steps to get the changes in place. What steps do you think are the best steps to getting the process changed up? So my thoughts in general on this (can be applied to any code based sub-project except node):
Job 1: build source (done on latest fedora and/or rhel host) generates source tarball generates srpm Can 1 srpm file support Fedora 17, Fedora 18, and EL6? Or will the build process create 3 srpm files one for each rpm based distro? Still learning about rpm spec files been in the .deb world for that last 8 years. In every case I've come across, yes.
exports both as artifacts Job 2: Build Fedora 17 RPMs takes srpm artifact from Job 1 uses mock to build F17 RPMs Job 2.5: Build Fedora 18 RPMs once Fedora starts beta testing? takes srpm artifact from Job 1 uses mock to build F17 RPMs Sure, but F18 RPMs. Copy and past error :)
BTW, with mock, we might even be able to build F17, F18, F*, EL* rpms all on one server. All depends on the mock config files, and fedora has one for EL6, fedora 14-17 and rawhide (18) Guess I need to learn more about mock. It would be nice to be able to build for more version then Just F17. Granted we would have to track features that are missing in diff builds but people like choice.
Job 3: Build EL6 RPMs takes srpm artifact from Job 1 uses mock to build EL6 RPMs Job 4-X: Build RPM for Distro XYZ takes either SRPM or tarball depending on distro build distro specific packages
As for the code to do each job, I don't know all the ins and outs of building each individual component, but something like a make dist and/or a make srpm should provide the needed artifacts.
I also don't know mock very well, but I'm pretty sure it's pretty straightforward for most packages.
Potential problems that I see:
1. spec files will need massaging for el6 and f17 diffs Can one spec file be used or will we need one for F17, F18, EL6? Yes, one spec is fine. Just need to have parts of it conditionalized for F17, F18, EL6...
2. will need distro specific spec file equivalents for each distro we support Yep. From what I can see of the format of the engine repo there shouldn't be any issue in just having debian packaging files in the repo and just pulling them out for the build process. 3. possible missing options to create srpm and src tarball
ovirt-node:
only really supported on fedora right now. We could possibly build packages for el6 and other distros that contain the fedora based iso, but not sure if that is really useful or not. EL6 builds would be nice not sure how many changes would be needed. Judging by the fact the current EL6 builds don't build nodes it is more then trivial. There was some work done to support Centos in the past, so it might not be too bad. I'll have to look closer though. That is good to know. I have always liked the node structure but tend to prefer CentOS so it would be great to have EL6 builds of node. As for an EL6 based image, that will take some work to figure out as well (and not sure if that's really a major driver at this point or not). If we are going to support EL6 it would be nice to have node builds for it. But time might better spent working on other projects. Agreed, it's lower prio for node than other projects.
Thanks Robert
Mike
Thanks Robert
> Thanks > Robert > _______________________________________________ > 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 Thanks Robert
On 07/12/2012 10:59 AM, Eyal Edri wrote:
----- Original Message -----
From: "Robert Middleswarth" <robert@middleswarth.net> To: "infra" <infra@ovirt.org> Sent: Thursday, July 12, 2012 5:44:44 PM Subject: Jenkins and RHEL 6.2
I see there are 2 RHEL 6.2 slaves added to Jenkins and I see they are doing something with the engine? What are they actually doing since I don't see any artifacts left over? How hard would it be to tweak the existing ones to create .rpms?
currently they are used for running mvn jobs like unit tests/find bugs.
you mean use them to create RPMs for ovirt-engine?
Yes
supposing make rpm will work for that, all we'll need is to make sure they have the right rpm build packages installed (rpmbuild, make,autoconf,etc....) I am sure there will be a need for some patches but we already know that oVirt 3.1 can work using EL6. This can wait until we move into 3.2 development mode but I really want official builds for 3.2 for EL6. I will go into more details in another reply.
Thanks Robert _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
participants (3)
-
Eyal Edri -
Mike Burns -
Robert Middleswarth