Testing sanlock development build with OST
Looking in https://jenkins.ovirt.org/job/ovirt-system-tests_manual/build <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/build?delay=0sec> CUSTOM_REPOS: You can add multiple Jenkins build urls/Yum repos, one per line. Supported formats are: * Jenkins Build url: e.g., http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-on-demand-el7-x86_6... * Yum repo: "rec:yum_repo_url" e.g., rec: http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-on-demand-el7-x86_6... It seems that this should work: 1. build sanlock rpms from my sanlock tree 2. copy to some public web server 3. create yum repo 4. add rec:http://my.server/sanlock-repo/ OST will pull sanlock from this repo, right? The biggest issue seems to be a public web server, I don't have one. Do we have something that I can use in jenkins.ovirt.org or other domain we control? I want to run these tests regularly, to make sure that sanlock always works with vdsm, without manual testing. Nir
On Sun, 19 May 2019 at 00:01, Nir Soffer <nsoffer@redhat.com> wrote:
Looking in https://jenkins.ovirt.org/job/ovirt-system-tests_manual/build <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/build?delay=0sec>
CUSTOM_REPOS:
You can add multiple Jenkins build urls/Yum repos, one per line. Supported formats are: * Jenkins Build url: e.g., http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-on-demand-el7-x86_6... * Yum repo: "rec:yum_repo_url" e.g., rec: http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-on-demand-el7-x86_6...
It doesn't actually have to be a yum repo, 'rec:' simply does a recursive HTTP crawl. `repoman` and therefore OST does not actually support reading YUM metadata ATM.
It seems that this should work:
1. build sanlock rpms from my sanlock tree 2. copy to some public web server 3. create yum repo
no need for that, but the web server needs to be browsable.
4. add rec:http://my.server/sanlock-repo/
OST will pull sanlock from this repo, right?
The biggest issue seems to be a public web server, I don't have one. Do we have something that I can use in jenkins.ovirt.org or other domain we control?
To be in jenkinsit needs to be build by jenkins...
I want to run these tests regularly, to make sure that sanlock always works with vdsm, without manual testing.
I think there are couple of solutions here you could consider: 1. Setup a build repo containing automation files for oVirt and have oVirt's CI system run the builds. this will enable full automation for the whole test process 2. Build via copr - in which case copt will provide HTTP hosting for the resulting RPMs.
Nir
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On Sun, May 19, 2019 at 8:43 AM Barak Korren <bkorren@redhat.com> wrote:
On Sun, 19 May 2019 at 00:01, Nir Soffer <nsoffer@redhat.com> wrote:
Looking in https://jenkins.ovirt.org/job/ovirt-system-tests_manual/build <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/build?delay=0sec>
CUSTOM_REPOS:
You can add multiple Jenkins build urls/Yum repos, one per line. Supported formats are: * Jenkins Build url: e.g., http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-on-demand-el7-x86_6... * Yum repo: "rec:yum_repo_url" e.g., rec: http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-on-demand-el7-x86_6...
It doesn't actually have to be a yum repo, 'rec:' simply does a recursive HTTP crawl. `repoman` and therefore OST does not actually support reading YUM metadata ATM.
It seems that this should work:
1. build sanlock rpms from my sanlock tree 2. copy to some public web server 3. create yum repo
no need for that, but the web server needs to be browsable.
4. add rec:http://my.server/sanlock-repo/
OST will pull sanlock from this repo, right?
The biggest issue seems to be a public web server, I don't have one. Do we have something that I can use in jenkins.ovirt.org or other domain we control?
To be in jenkinsit needs to be build by jenkins...
I want to run these tests regularly, to make sure that sanlock always works with vdsm, without manual testing.
I think there are couple of solutions here you could consider:
1. Setup a build repo containing automation files for oVirt and have oVirt's CI system run the builds. this will enable full automation for the whole test process
Do you mean project without any source, only stdci.yaml and build script
Thanks, testing with latest build now: rec:https://cbs.centos.org/kojifiles/packages/sanlock/3.7.3/1.el7/x86_64/ https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4764/ pulling sanlock source from master, and creating rpms? Can we use my sanlock fork on github for this? https://github.com/nirs/sanlock
1. Build via copr - in which case copt will provide HTTP hosting for the resulting RPMs.
Interesting, but I think I need cbs instead, since we don't have Fedora
OST yet. I think the simplest way would something like fedpkg scratch build use the build URL. Sandro, what do I need to be able to do scratch builds in cbs? https://cbs.centos.org/koji/index Nir
On Wed, 22 May 2019 at 21:07, Nir Soffer <nsoffer@redhat.com> wrote:
On Sun, May 19, 2019 at 8:43 AM Barak Korren <bkorren@redhat.com> wrote:
On Sun, 19 May 2019 at 00:01, Nir Soffer <nsoffer@redhat.com> wrote:
Looking in https://jenkins.ovirt.org/job/ovirt-system-tests_manual/build <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/build?delay=0sec>
CUSTOM_REPOS:
You can add multiple Jenkins build urls/Yum repos, one per line. Supported formats are: * Jenkins Build url: e.g., http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-on-demand-el7-x86_6... * Yum repo: "rec:yum_repo_url" e.g., rec: http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-on-demand-el7-x86_6...
It doesn't actually have to be a yum repo, 'rec:' simply does a recursive HTTP crawl. `repoman` and therefore OST does not actually support reading YUM metadata ATM.
Thanks, testing with latest build now: rec:https://cbs.centos.org/kojifiles/packages/sanlock/3.7.3/1.el7/x86_64/
https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4764/
It seems that this should work:
1. build sanlock rpms from my sanlock tree 2. copy to some public web server 3. create yum repo
no need for that, but the web server needs to be browsable.
4. add rec:http://my.server/sanlock-repo/
OST will pull sanlock from this repo, right?
The biggest issue seems to be a public web server, I don't have one. Do we have something that I can use in jenkins.ovirt.org or other domain we control?
To be in jenkinsit needs to be build by jenkins...
I want to run these tests regularly, to make sure that sanlock always works with vdsm, without manual testing.
I think there are couple of solutions here you could consider:
1. Setup a build repo containing automation files for oVirt and have oVirt's CI system run the builds. this will enable full automation for the whole test process
Do you mean project without any source, only stdci.yaml and build script pulling sanlock source from master, and creating rpms?
Yes, only you don't actually have to write the logic to pull the other source yourself, we already have tooling for that that will keep things reproducible: https://ovirt-infra-docs.readthedocs.io/en/latest/CI/Build_and_test_standard...
Can we use my sanlock fork on github for this? https://github.com/nirs/sanlock
Doesn't have to be a fork of the existing sanlok repo, but we can use gitHub for that, yeah. I'd rather we use something in oVirt's org though to save some time setting up credentials and permissions.
1. Build via copr - in which case copt will provide HTTP hosting for the resulting RPMs.
Interesting, but I think I need cbs instead, since we don't have Fedora OST yet.
Copr can build for CentOS too (Its called EPEL there, but its essentialy using the same mock we use in our CI for emulating CentOS).
I think the simplest way would something like fedpkg scratch build use the build URL.
Putting Koji into the mix never makes thing simpler....
Sandro, what do I need to be able to do scratch builds in cbs? https://cbs.centos.org/koji/index
I think that would actually be an overkill... -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
participants (2)
-
Barak Korren -
Nir Soffer