- Infra - oVirt List Archives

[JIRA] (OVIRT-1871) Wrong target milestone check on new 4.2 branches for ovirt-host-deploy
by sbonazzo (oVirt JIRA) 01 Feb '18

01 Feb '18

This is a multi-part message in MIME format... ------------=_1517478412-20389-117 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit sbonazzo created OVIRT-1871: ------------------------------- Summary: Wrong target milestone check on new 4.2 branches for ovirt-host-deploy Key: OVIRT-1871 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1871 Project: oVirt - virtualization made easy Issue Type: Bug Components: Gerrit/git Reporter: sbonazzo Assignee: infra I branched ovirt-host-deploy for 4.2 stabilization and on the new branch named ovirt-host-deploy-1.7 I get: Check TM::#1539040::WARN, wrong target milestone: ovirt-4.2.1 (-1) https://gerrit.ovirt.org/#/c/86992/ I'd like to configure the hook to match the branch with the ovirt-4.2* target milestones but couldn't find documentation on how to do that. When fixing this, please also include link to how to do that, I've other projects that will need similar change. -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078) ------------=_1517478412-20389-117 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <h3>sbonazzo created OVIRT-1871:</h3> <pre> Summary: Wrong target milestone check on new 4.2 branches for ovirt-host-deploy Key: OVIRT-1871 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1871 Project: oVirt - virtualization made easy Issue Type: Bug Components: Gerrit/git Reporter: sbonazzo Assignee: infra</pre> <p>I branched ovirt-host-deploy for 4.2 stabilization and on the new branch named ovirt-host-deploy-1.7 I get: Check TM::#1539040::WARN, wrong target milestone: ovirt-4.2.1 (-1) <a href="https://gerrit.ovirt.org/#/c/86992/">https://gerrit.ovirt.org/#/c/86992/</a> I'd like to configure the hook to match the branch with the ovirt-4.2* target milestones but couldn't find documentation on how to do that. When fixing this, please also include link to how to do that, I've other projects that will need similar change.</p> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1517478412-20389-117--

1 0

[JIRA] (OVIRT-1712) OST jobs fails on "address already in use"
by Daniel Belenky (oVirt JIRA) 01 Feb '18

01 Feb '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1712?page=com.atlassian.jira.… ] Daniel Belenky commented on OVIRT-1712: --------------------------------------- [~eedri] We'll probably add a cleanup function to global setup to ensure that lago can run smoothly. I'll talk with [~gbenhaim(a)redhat.com] offline to see what needs to be done. > OST jobs fails on "address already in use" > ------------------------------------------ > > Key: OVIRT-1712 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1712 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: eyal edri > Assignee: Gal Ben Haim > Priority: High > > Evgheni, > Was there any change recently to Lago slaves? > On Fri, Oct 20, 2017 at 11:05 AM, Piotr Kliczewski < > piotr.kliczewski(a)gmail.com> wrote: > > I attempted to run manual OST twice and both failed with below issue. > > Can someone take a look? > > > > Thanks, > > Piotr > > > > 2017-10-20 07:59:12,485::log_utils.py::__exit__::607::ovirtlago.prefix: > > :DEBUG:: > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > > > 2017-10-20 07:59:12,485::cmd.py::do_run::365::root::ERROR::Error > > occured, aborting > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 362, in > > do_run > > self.cli_plugins[args.ovirtverb].do_run(args) > > File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line > > 184, in do_run > > self._do_run(**vars(args)) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in > > wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in > > wrapper > > return func(*args, prefix=prefix, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 166, > > in do_deploy > > prefix.deploy() > > File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, > > in wrapper > > return func(*args, **kwargs) > > File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line > > 111, in wrapper > > with utils.repo_server_context(args[0]): > > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > > return self.gen.next() > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line > > 100, in repo_server_context > > root_dir=prefix.paths.internal_repo(), > > File "/usr/lib/python2.7/site-packages/ovirtlago/utils.py", line 76, > > in _create_http_server > > generate_request_handler(root_dir), > > File "/usr/lib64/python2.7/SocketServer.py", line 419, in __init__ > > self.server_bind() > > File "/usr/lib64/python2.7/BaseHTTPServer.py", line 108, in server_bind > > SocketServer.TCPServer.server_bind(self) > > File "/usr/lib64/python2.7/SocketServer.py", line 430, in server_bind > > self.socket.bind(self.server_address) > > File "/usr/lib64/python2.7/socket.py", line 224, in meth > > return getattr(self._sock,name)(*args) > > error: [Errno 98] Address already in use > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > -- > Eyal edri > MANAGER > RHV DevOps > EMEA VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078)

1 0

[JIRA] (OVIRT-1870) kubevirt_kubevirt_standard-check-pr jobs often get stuck
by Barak Korren (oVirt JIRA) 01 Feb '18

01 Feb '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1870?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1870: -------------------------------- Epic Link: OVIRT-400 > kubevirt_kubevirt_standard-check-pr jobs often get stuck > -------------------------------------------------------- > > Key: OVIRT-1870 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1870 > Project: oVirt - virtualization made easy > Issue Type: Bug > Components: CI client projects, Standard CI (Pipelines) > Reporter: Evgheni Dereveanchin > Assignee: infra > > kubevirt_kubevirt_standard-check-pr jobs often get stuck waiting forever for a connection to get established: > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/376/console > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/377/console > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/378/console > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/380/console > The following message keeps repeating all the time: > 17:03:32 [check-patch.el7.x86_64] ++ awk '/virt-controller/ && /true/' > 17:03:32 [check-patch.el7.x86_64] ++ kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:32 [check-patch.el7.x86_64] ++ wc -l > 17:03:32 [check-patch.el7.x86_64] ++ cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:44 [check-patch.el7.x86_64] Unable to connect to the server: dial tcp 192.168.121.111:6443: getsockopt: no route to host > 17:03:44 [check-patch.el7.x86_64] + '[' 0 -lt 1 ']' > 17:03:44 [check-patch.el7.x86_64] + echo 'Waiting for KubeVirt virt-controller container to become ready ...' > 17:03:44 [check-patch.el7.x86_64] Waiting for KubeVirt virt-controller container to become ready ... > 17:03:44 [check-patch.el7.x86_64] + kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:44 [check-patch.el7.x86_64] + awk '/virt-controller/ && /true/' > 17:03:44 [check-patch.el7.x86_64] + cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:44 [check-patch.el7.x86_64] + wc -l > 17:03:56 [check-patch.el7.x86_64] Unable to connect to the server: dial tcp 192.168.121.111:6443: getsockopt: no route to host > 17:03:56 [check-patch.el7.x86_64] 0 > 17:03:56 [check-patch.el7.x86_64] + sleep 10 > Need to implement timeouts as this takes up bare metal systems for days and weeks until someone manually kills the job -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078)

1 0

[JIRA] (OVIRT-1870) kubevirt_kubevirt_standard-check-pr jobs often get stuck
by Barak Korren (oVirt JIRA) 01 Feb '18

01 Feb '18

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1870?page=com.atlassian.jira.… ] Barak Korren reassigned OVIRT-1870: ----------------------------------- Assignee: Barak Korren (was: infra) Component/s: Standard CI (Pipelines) CI client projects Epic Link: OVIRT-400 Issue Type: Outage (was: Bug) Priority: Highest (was: Medium) > kubevirt_kubevirt_standard-check-pr jobs often get stuck > -------------------------------------------------------- > > Key: OVIRT-1870 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1870 > Project: oVirt - virtualization made easy > Issue Type: Outage > Components: CI client projects, Standard CI (Pipelines) > Reporter: Evgheni Dereveanchin > Assignee: Barak Korren > Priority: Highest > > kubevirt_kubevirt_standard-check-pr jobs often get stuck waiting forever for a connection to get established: > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/376/console > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/377/console > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/378/console > http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/380/console > The following message keeps repeating all the time: > 17:03:32 [check-patch.el7.x86_64] ++ awk '/virt-controller/ && /true/' > 17:03:32 [check-patch.el7.x86_64] ++ kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:32 [check-patch.el7.x86_64] ++ wc -l > 17:03:32 [check-patch.el7.x86_64] ++ cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:44 [check-patch.el7.x86_64] Unable to connect to the server: dial tcp 192.168.121.111:6443: getsockopt: no route to host > 17:03:44 [check-patch.el7.x86_64] + '[' 0 -lt 1 ']' > 17:03:44 [check-patch.el7.x86_64] + echo 'Waiting for KubeVirt virt-controller container to become ready ...' > 17:03:44 [check-patch.el7.x86_64] Waiting for KubeVirt virt-controller container to become ready ... > 17:03:44 [check-patch.el7.x86_64] + kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:44 [check-patch.el7.x86_64] + awk '/virt-controller/ && /true/' > 17:03:44 [check-patch.el7.x86_64] + cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers > 17:03:44 [check-patch.el7.x86_64] + wc -l > 17:03:56 [check-patch.el7.x86_64] Unable to connect to the server: dial tcp 192.168.121.111:6443: getsockopt: no route to host > 17:03:56 [check-patch.el7.x86_64] 0 > 17:03:56 [check-patch.el7.x86_64] + sleep 10 > Need to implement timeouts as this takes up bare metal systems for days and weeks until someone manually kills the job -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100078)

1 0

[JIRA] (OVIRT-1870) kubevirt_kubevirt_standard-check-pr jobs often get stuck
by Evgheni Dereveanchin (oVirt JIRA) 31 Jan '18

31 Jan '18

Evgheni Dereveanchin created OVIRT-1870: ------------------------------------------- Summary: kubevirt_kubevirt_standard-check-pr jobs often get stuck Key: OVIRT-1870 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1870 Project: oVirt - virtualization made easy Issue Type: Bug Reporter: Evgheni Dereveanchin Assignee: infra kubevirt_kubevirt_standard-check-pr jobs often get stuck waiting forever for a connection to get established: http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/376/console http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/377/console http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/378/console http://jenkins.ovirt.org/job/kubevirt_kubevirt_standard-check-pr/380/console The following message keeps repeating all the time: 17:03:32 [check-patch.el7.x86_64] ++ awk '/virt-controller/ && /true/' 17:03:32 [check-patch.el7.x86_64] ++ kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers 17:03:32 [check-patch.el7.x86_64] ++ wc -l 17:03:32 [check-patch.el7.x86_64] ++ cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers 17:03:44 [check-patch.el7.x86_64] Unable to connect to the server: dial tcp 192.168.121.111:6443: getsockopt: no route to host 17:03:44 [check-patch.el7.x86_64] + '[' 0 -lt 1 ']' 17:03:44 [check-patch.el7.x86_64] + echo 'Waiting for KubeVirt virt-controller container to become ready ...' 17:03:44 [check-patch.el7.x86_64] Waiting for KubeVirt virt-controller container to become ready ... 17:03:44 [check-patch.el7.x86_64] + kubectl get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers 17:03:44 [check-patch.el7.x86_64] + awk '/virt-controller/ && /true/' 17:03:44 [check-patch.el7.x86_64] + cluster/kubectl.sh get pods -n kube-system '-ocustom-columns=status:status.containerStatuses[*].ready,metadata:metadata.name' --no-headers 17:03:44 [check-patch.el7.x86_64] + wc -l 17:03:56 [check-patch.el7.x86_64] Unable to connect to the server: dial tcp 192.168.121.111:6443: getsockopt: no route to host 17:03:56 [check-patch.el7.x86_64] 0 17:03:56 [check-patch.el7.x86_64] + sleep 10 Need to implement timeouts as this takes up bare metal systems for days and weeks until someone manually kills the job -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)

1 0

Build failed in Jenkins: system-sync_mirrors-centos-updates-el7-x86_64 #1229
by jenkins＠jenkins.phx.ovirt.org 31 Jan '18

31 Jan '18

See <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_64/…> Changes: [Dafna Ron] ovirt-host-deploy - dropping fc24 [Sandro Bonazzola] ovirt-host-deploy: re-align [Dafna Ron] ovirt-engine-wildfly - dropping fc24 [Sandro Bonazzola] ovirt-engine-wildfly: re-align [Evgheni Dereveanchin] Update mirror snapshot for FC27 to fix gdbm [Dafna Ron] ovirt-engine-wildfly-overlay - dropping fc24 [Sandro Bonazzola] ovirt-engine-wildfly-overlay: re-align [Gal Ben Haim] kubevirt-ansible: Update org [Sandro Bonazzola] ovirt-setup-lib: branched for 4.3 development [Sandro Bonazzola] ovirt-guest-agent: re-align [Nir Soffer] ioprocess: Add project for 4.2 [Martin Sivak] Cleanup and prepare SLA packages for 4.2 ------------------------------------------ Started by timer [EnvInject] - Loading node environment variables. Building remotely on mirrors.phx.ovirt.org (mirrors) in workspace <http://jenkins.ovirt.org/job/system-sync_mirrors-centos-updates-el7-x86_64/…> > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url http://gerrit.ovirt.org/jenkins.git # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 > git clean -fdx # timeout=10 Pruning obsolete local branches Fetching upstream changes from http://gerrit.ovirt.org/jenkins.git > git --version # timeout=10 > git fetch --tags --progress http://gerrit.ovirt.org/jenkins.git +refs/heads/*:refs/remotes/origin/* --prune > git rev-parse origin/master^{commit} # timeout=10 Checking out Revision 1b9164a35a85fde7ff0218fa6cacfed04472e381 (origin/master) > git config core.sparsecheckout # timeout=10 > git checkout -f 1b9164a35a85fde7ff0218fa6cacfed04472e381 Commit message: "Cleanup and prepare SLA packages for 4.2" > git rev-list 7884783969141c572c6a8fd1331a612ecfa542ac # timeout=10 [system-sync_mirrors-centos-updates-el7-x86_64] $ /bin/bash -xe /tmp/jenkins5771763202377004232.sh + jenkins/scripts/mirror_mgr.sh resync_yum_mirror centos-updates-el7 x86_64 jenkins/data/mirrors-reposync.conf Checking if mirror needs a resync Traceback (most recent call last): File "/usr/bin/reposync", line 343, in <module> main() File "/usr/bin/reposync", line 175, in main my.doRepoSetup() File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 681, in doRepoSetup return self._getRepos(thisrepo, True) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 721, in _getRepos self._repos.doSetup(thisrepo) File "/usr/lib/python2.7/site-packages/yum/repos.py", line 157, in doSetup self.retrieveAllMD() File "/usr/lib/python2.7/site-packages/yum/repos.py", line 88, in retrieveAllMD dl = repo._async and repo._commonLoadRepoXML(repo) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 1465, in _commonLoadRepoXML local = self.cachedir + '/repomd.xml' File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 774, in <lambda> cachedir = property(lambda self: self._dirGetAttr('cachedir')) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 757, in _dirGetAttr self.dirSetup() File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 735, in dirSetup self._dirSetupMkdir_p(dir) File "/usr/lib/python2.7/site-packages/yum/yumRepo.py", line 712, in _dirSetupMkdir_p raise Errors.RepoError, msg yum.Errors.RepoError: Error making cache directory: /home/jenkins/mirrors_cache/centos-updates-el7/gen error was: [Errno 17] File exists: '/home/jenkins/mirrors_cache/centos-updates-el7/gen' Build step 'Execute shell' marked build as failure

1 1

oVirt infra weekly meeting notes 31.01.2018
by Evgheni Dereveanchin 31 Jan '18

31 Jan '18

Hi everyone, Please find the topics of this week's infra meeting below: PHX DC - Core network equipment change completed on Monday - Repo definitions removed from puppet as part of OVIRT-1810 <https://ovirt-jira.atlassian.net/browse/OVIRT-1810> - New Fedora 27 snapshot enabled to fix GDBM issue OVIRT-1839 <https://ovirt-jira.atlassian.net/browse/OVIRT-1839> - Issue with lago port taken on slaves showing up again OVIRT-1712 <https://ovirt-jira.atlassian.net/browse/OVIRT-1712> - Disk filling on templates.ovirt.org OVIRT-1869 <https://ovirt-jira.atlassian.net/browse/OVIRT-1869> - Kubevirt jobs take up slaves -> open ticket - Jenkins update tested on Staging OVIRT-1858 <https://ovirt-jira.atlassian.net/browse/OVIRT-1858> AI - Import CoreOS to glance -- Regards, Evgheni Dereveanchin

1 0

[CQ]: 83154,4 (ovirt-engine-wildfly) failed "ovirt-4.2" system tests
by oVirt Jenkins 31 Jan '18

31 Jan '18

Change 83154,4 (ovirt-engine-wildfly) is probably the reason behind recent system test failures in the "ovirt-4.2" change queue and needs to be fixed. This change had been removed from the testing queue. Artifacts build from this change will not be released until it is fixed. For further details about the change see: https://gerrit.ovirt.org/#/c/83154/4 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/385/

1 0

[JIRA] (OST-99) new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium
by eyal edri (oVirt JIRA) 31 Jan '18

31 Jan '18

This is a multi-part message in MIME format... ------------=_1517412734-27111-145 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit [ https://ovirt-jira.atlassian.net/browse/OST-99?page=com.atlassian.jira.plug… ] eyal edri moved OVIRT-1788 to OST-99: ------------------------------------- Component/s: (was: OST) Project: oVirt system tests (was: oVirt - virtualization made easy) Workflow: Software Simplified Workflow for Project OST (was: Task Management Workflow) Key: OST-99 (was: OVIRT-1788) > new ui_sanity scenario for basic_suite -- need multiple firefoxes and chromium > ------------------------------------------------------------------------------ > > Key: OST-99 > URL: https://ovirt-jira.atlassian.net/browse/OST-99 > Project: oVirt system tests > Issue Type: Improvement > Reporter: Greg Sheremeta > Assignee: infra > > I'm writing a suite that does headless UI testing. One goal is to open headless firefox and actually open the UI, perform a login, make sure things look good, make sure there are no ui.log errors, etc. I'll also eventually add chromium, which can run headless now too. > The suite requires several firefox versions to be installed on the test machine, along with chromium. There are also some binary components required, geckodriver and chromedriver. These are not packaged. > Ideally the browsers can be installed to /opt/firefox55, /opt/firefox56, /opt/chromium62, etc. on the machine running the suite. So I think it makes sense to maintain a custom rpm with all of this. > Where can this rpm live? What is a reliable way to do this? (I know we want to avoid copr.) -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077) ------------=_1517412734-27111-145 Content-Type: text/html; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit <html><body> <pre>[ https://ovirt-jira.atlassian.net/browse/OST-99?page=com.atlassian.jira.plug… ]</pre> <h3>eyal edri moved OVIRT-1788 to OST-99:</h3> <pre> Component/s: (was: OST) Project: oVirt system tests (was: oVirt - virtualization made easy) Workflow: Software Simplified Workflow for Project OST (was: Task Management Workflow) Key: OST-99 (was: OVIRT-1788)</pre> <blockquote><h3>new ui_sanity scenario for basic_suite — need multiple firefoxes and chromium</h3> <pre> Key: OST-99 URL: https://ovirt-jira.atlassian.net/browse/OST-99 Project: oVirt system tests Issue Type: Improvement Reporter: Greg Sheremeta Assignee: infra</pre> <p>I'm writing a suite that does headless UI testing. One goal is to open headless firefox and actually open the UI, perform a login, make sure things look good, make sure there are no ui.log errors, etc. I'll also eventually add chromium, which can run headless now too. The suite requires several firefox versions to be installed on the test machine, along with chromium. There are also some binary components required, geckodriver and chromedriver. These are not packaged. Ideally the browsers can be installed to /opt/firefox55, /opt/firefox56, /opt/chromium62, etc. on the machine running the suite. So I think it makes sense to maintain a custom rpm with all of this. Where can this rpm live? What is a reliable way to do this? (I know we want to avoid copr.)</p></blockquote> <p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)</p> <img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3…" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/> </body></html> ------------=_1517412734-27111-145--

1 0

[CQ]: 86940, 3 (ovirt-setup-lib) failed "ovirt-4.2" system tests, but isn't the failure root cause
by oVirt Jenkins 31 Jan '18

31 Jan '18

A system test invoked by the "ovirt-4.2" change queue including change 86940,3 (ovirt-setup-lib) failed. However, this change seems not to be the root cause for this failure. Change 86938,2 (ovirt-setup-lib) that this change depends on or is based on, was detected as the cause of the testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 86938,2 (ovirt-setup-lib) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/86940/3 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/86938/2 For failed test results see: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/383/

1 0