March 2019 - Devel - oVirt List Archives

[ OST Failure Report ] [ oVirt master (ovirt-engine) ] [ 10-03-19 ] [ verify_glance_import ]
by Liora Milbaum 10 Mar '19

10 Mar '19

Link and headline of suspected patches: Link to Job: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13310/ Link to all logs: (Relevant) error snippet from the log: <error> [36m@ Run test: 004_basic_sanity.py: [0m [0m [0m nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] [36m # verify_glance_import: [0m [0m [0m [31m * Unhandled exception in <function <lambda> at 0x7f9f147cbed8> Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 234, in assert_equals_within res = func() File "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/004_basic_sanity.py", line 1153, in <lambda> lambda: api.disks.get(disk_name).status.state == 'ok', AttributeError: 'NoneType' object has no attribute 'status' [0m [36m * Collect artifacts: [0m [0m [0m [36m ~ [Thread-4] Copy from lago-basic-suite-master-engine:/tmp/otopi* to /dev/shm/ost/deployment-basic-suite-master/default/test_logs/004_basic_sanity.verify_glance_import-20190307161910/lago-basic-suite-master-engine/_tmp_otopi*: [31mERROR [0m (in 0:00:00) [0m [36m - [Thread-4] lago-basic-suite-master-engine: [31mERROR [0m (in 0:00:00) [0m [36m * Collect artifacts: [31mERROR [0m (in 0:00:02) [0m [36m # verify_glance_import: [31mERROR [0m (in 0:00:02) [0m [36m # Results located at /dev/shm/ost/deployment-basic-suite-master/004_basic_sanity.py.junit.xml [0m [36m@ Run test: 004_basic_sanity.py: [31mERROR [0m (in 0:00:02) [0m [31mError occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 383, 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 549, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 560, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 107, in do_ovirt_runtest raise RuntimeError('Some tests failed') RuntimeError: Some tests failed [0m </error> -- *Liora Milbaum* Senior Principal Software Engineer RHV/CNV DevOps EMEA VIRTUALIZATION R&D T: +972-54-6560051 <https://red.ht/sig>

2 1

[ OST Failure Report ] [ oVirt Master (ovirt-engine-nodejs-modules) ] [ 27-02-2019 ] [ 002_bootstrap.add_vm2_lease ]
by Dafna Ron 10 Mar '19

10 Mar '19

Hi, We have a failure on the project in basic suite, master branch. The recent failure was in patch: https://gerrit.ovirt.org/#/c/98087/1 - Add pre-seed for ovirt-web-ui CQ is pointing at the below as the root cause (which was merged a while back): https://gerrit.ovirt.org/#/c/97491/ - Add pre-seed for ovirt-web-ui Can you please check the issue as it seems both patches are changing the same thing and the project seem to be broken since https://gerrit.ovirt.org/#/c/97491/3 Latest failure: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13171/ Logs: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13171/artifa… errors from logs: Engine: 2019-02-27 13:37:28,479-05 ERROR [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [74283e25] Transaction rolled-back for command 'org.ovirt.engine.core.bll.UpdateVmCommand'. 2019-02-27 13:37:28,483-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [74283e25] EVENT_ID: USER_FAILED_UPDATE_VM(58), Failed to update VM vm2 (User: admin@inter nal-authz). 2019-02-27 13:37:28,485-05 INFO [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [74283e25] Lock freed to object 'EngineLock:{exclusiveLocks='[vm2=VM_NAME]', sharedLocks='[3500eb82-e5e2-4e24-b41c-ea 02d9f6adee=VM]'}' 2019-02-27 13:37:28,485-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-1) [74283e25] method: runAction, params: [UpdateVm, VmManagementParametersBase:{commandId='340 59769-05b9-429e-8356-f6b9b9953f55', user='admin', commandType='UpdateVm', vmId='3500eb82-e5e2-4e24-b41c-ea02d9f6adee'}], timeElapsed: 6618ms 2019-02-27 13:37:28,486-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-1) [] Operation Failed: [] 2019-02-27 13:37:28,579-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (EE-ManagedThreadFactory-engineScheduled-Thread-85) [] method: get, params: [e29c0ba1-464c-4eb4-a8f2-c6933d9 9969a], timeElapsed: 3ms vdsm: 2019-02-27 13:37:21,987-0500 INFO (jsonrpc/1) [vdsm.api] FINISH lease_info error=No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee from=::ffff:192.168.201.4,43920, flow_id=117dec74-ad59-4b12-8148-b2c130337c10, task_id=9c297d41-0aa7-4c74-b268-b710e666bc6c (api:52) 2019-02-27 13:37:21,988-0500 ERROR (jsonrpc/1) [storage.TaskManager.Task] (Task='9c297d41-0aa7-4c74-b268-b710e666bc6c') Unexpected error (task:875) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in _run return fn(*args, **kargs) File "<string>", line 2, in lease_info File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50, in method ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3702, in lease_info info = dom.lease_info(lease.lease_id) File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 674, in lease_info return vol.lookup(lease_id) File "/usr/lib/python2.7/site-packages/vdsm/storage/xlease.py", line 553, in lookup raise NoSuchLease(lease_id) NoSuchLease: No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee 2019-02-27 13:37:21,988-0500 INFO (jsonrpc/1) [storage.TaskManager.Task] (Task='9c297d41-0aa7-4c74-b268-b710e666bc6c') aborting: Task is aborted: u'No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee' - code 100 (task:1181) 2019-02-27 13:37:21,988-0500 ERROR (jsonrpc/1) [storage.Dispatcher] FINISH lease_info error=No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee (dispatcher:87) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/dispatcher.py", line 74, in wrapper result = ctask.prepare(func, *args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 108, in wrapper return m(self, *a, **kw) File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 1189, in prepare raise self.error NoSuchLease: No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee

5 9

ovirt-vmconsole-1.0.6-3.fc28.noarch: Non-fatal POSTUN scriptlet failure
by Nir Soffer 10 Mar '19

10 Mar '19

When updating Fedora 28 host with ovirt-release-master repo, I see this error: Running scriptlet: ovirt-vmconsole-1.0.6-3.fc28.noarch 143/251 libsemanage.semanage_module_key_set_name: Name /usr/share/selinux/packages/ovirt-vmconsole/ovirt_vmconsole.pp is invalid. semodule: Failed on /usr/share/selinux/packages/ovirt-vmconsole/ovirt_vmconsole.pp! warning: %postun(ovirt-vmconsole-1.0.6-3.fc28.noarch) scriptlet failed, exit status 1 Non-fatal POSTUN scriptlet failure in rpm package ovirt-vmconsole Non-fatal POSTUN scriptlet failure in rpm package ovirt-vmconsole I did not try to use it, I don't know if we have a real issue. Looks like we need to either fix the issue or silence the warnings. Nir

2 1

[Ovirt] [CQ weekly status] [08-03-2019]
by Dafna Ron 09 Mar '19

09 Mar '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#1) Last CQ job failure on 4.2 was 06-03-2019 on project ovirt-ansible-vm-infra due to missing jtk2 package. this issue is now fixed with patch: https://gerrit.ovirt.org/#/c/98304/ *CQ-4.3*: RED (#1) Last job to fail is for project imgbased. the failure is due to the random failures we have been having from test add_vm2_lease. this issue is currently debated in the list. New repo and packages were updated by Galit due to failure in CQ for missing packages: https://gerrit.ovirt.org/#/c/98312/ *CQ-Master:* RED (#1) We were failing this week due to missing packages which was fixed by: https://gerrit.ovirt.org/#/c/98304/ We also had two regressions which were fixed by: https://gerrit.ovirt.org/#/c/98317/ and by https://gerrit.ovirt.org/#/c/98371/ All projects are currently passing Current running jobs for 4.2 [1] and master [2] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… Happy week! Dafna ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3)

1 1

ovirt and AMD virtualization bug
by Hetz Ben Hamo 09 Mar '19

09 Mar '19

Hi, I've done some research on a bug which I found on the AMD Zen/Zen+ based CPU's. Apparently, when using nested virtualization, the CPU doesn't expose the "monitor" CPU flag. While other virtualization solutions (Xen, ESXi, Hyper-V) don't care about this issue and let you run with nested without any problem, oVirt doesn't let you launch or create any VM and it complains that this "monitor" CPU flag is missing. Since QEMU/KVM cannot do anything about it, I was wondering if the ovirt dev team could ignore this flag please. Thanks

2 1

[VDSM] build-artifacts on s390x broken again (bad mock/dnf cache?)
by Nir Soffer 09 Mar '19

09 Mar '19

build-artifacts on s390x fail now with: [Errno 2] No such file or directory: '/var/cache/dnf/updates-07b7057ee4fded96/packages/systemd-238-12.git07f8cd5.fc28.s390x.rpm' Here are few example failures: https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa… https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa… This is going to block the change queue when we merge these patches, and we have 4.3 build soon. We had this issue few week ago, and Barak fixed this by deleting caches on the slaves. I hope this can be fixed quickly this time. Nir

1 0

ovirt-optimizer: subproject health check
by Sandro Bonazzola 08 Mar '19

08 Mar '19

Hi, oVirt Optimizer has been introduced in oVirt 3.5.2 back in 2014. Last update on master branch is dated November 2017 with version 0.15 The package has been shipped till oVirt 4.2.8 and it has not been shipped in oVirt 4.3 despite no official deprecation has been announced. According to Gerrit, current maintainers are Doron Fediuck and Martin Sivak. According to Bugzilla there is one bug open since February 2018: Bug 1545077 <https://bugzilla.redhat.com/show_bug.cgi?id=1545077> - cancel optimization button is enabled all the time which is currently untargeted, unassigned and without activity since March 2018. The project has feature / development documentation at https://ovirt.org/develop/release-management/features/sla/optaplanner.html but no official documentation. Can we declare this subproject retired from oVirt project and drop CI automation for it? Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

ovirt-scheduler-proxy: subproject health check
by Sandro Bonazzola 08 Mar '19

08 Mar '19

Hi, oVirt Scheduler Proxy has been introduced in oVirt 3.3.1 back in 2013. Last update on master branch is dated November 2017 with 0.1.8 released. The package has been shipped till oVirt 4.2.8 and it has not been shipped in oVirt 4.3 despite no official deprecation has been announced. According to Gerrit, current maintainers are Doron Fediuck and Martin Sivak. According to Bugzilla there are no open bugs or RFEs for this project. The project has no documentation available on oVirt website. Can we declare this subproject retired from oVirt project and drop CI automation for it? Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 2

[ci test tool] how to start build-artifacts job using jenkins API?
by Nir Soffer 08 Mar '19

08 Mar '19

I'm trying to a write a tool that given a gerrit patch number, will: 1. Start build artifacts job (instead of adding "ci please build" comment)\ 2. Wait until the job is complete 3. Start OST with CUSTOM_REPOS using the build artifacts job from step 1 4. Wait until OST complets 5. Post a comment with the OST link to gerrit So testing patches will easy as: $ ci test 12345 Building rpms... Starting OST... OST succeeded, congratulations! I can start OST and watch it, but I could not find a way to start vdsm build-artifacts job. This starts a job: curl -i \ --user USERNAME:API_TOKEN \ -X POST \ https://jenkins.ovirt.org/job/vdsm_standard-check-patch/build But the fail quickly in the first "detecting" stage. https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa… Clicking "Build Now" button on the job page fails in the same way. And this: curl -i \ --user USERNAME:API_TOKEN \ -X POST \ https://jenkins.ovirt.org/job/vdsm_standard-check-patch/buildWithParameters Fails with 500 Internal server error, with a huge traceback, hiding this expected message: java.lang.IllegalStateException: This build is not parameterized! Looks like the job need to be parametrized: - https://jenkins.ovirt.org/job/vdsm_standard-check-patch/configure - https://jenkins.ovirt.org/job/ovirt-system-tests_manual/configure I guess we can workaround this by posting "ci please build" comment on gerrit using gerrit API, and then waiting waiting an grabbing the build link from the comment added by jenkins, but I really don't want to go in this direction. I hope we can have a proper solution in the job configuration. Nir

1 1

[ OST Failure Report ] [ oVirt Master ] [ 07-03-2019 ] [ 008_basic_ui_sanity.initialize_firefox]
by Galit Rosenthal 07 Mar '19

07 Mar '19

Hi, we are failing basic suite master (vdsm) Can you please have a look at the issue? *Error Message:* Message: Error forwarding the new session new session request for webdriver should contain a location header or an 'application/json;charset=UTF-8' response body with the session ID. *from the [2]:* *08:22:04* + xmllint --format /dev/shm/ost/deployment-basic-suite-master/008_basic_ui_sanity.py.junit.xml*08:22:04* <?xml version="1.0" encoding="UTF-8"?>*08:22:04* <testsuite name="nosetests" tests="7" errors="1" failures="0" skip="0">*08:22:04* <testcase classname="008_basic_ui_sanity" name="init" time="0.001"/>*08:22:04* <testcase classname="008_basic_ui_sanity" name="start_grid" time="144.413">*08:22:04* <system-out><![CDATA[executing shell: docker ps*08:22:04* CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES*08:22:04* *08:22:04* *08:22:04* executing shell: docker rm -f grid_node_chrome grid_node_firefox selenium-hub*08:22:04* *08:22:04* Error response from daemon: No such container: grid_node_chrome*08:22:04* Error response from daemon: No such container: grid_node_firefox*08:22:04* Error response from daemon: No such container: selenium-hub*08:22:04* *08:22:04* executing shell: docker kill grid_node_chrome grid_node_firefox selenium-hub*08:22:04* *08:22:04* Error response from daemon: Cannot kill container grid_node_chrome: No such container: grid_node_chrome*08:22:04* Error response from daemon: Cannot kill container grid_node_firefox: No such container: grid_node_firefox*08:22:04* Error response from daemon: Cannot kill container selenium-hub: No such container: selenium-hub*08:22:04* *08:22:04* executing shell: docker ps*08:22:04* CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES*08:22:04* *08:22:04* *08:22:04* executing shell: docker network ls*08:22:04* NETWORK ID NAME DRIVER SCOPE*08:22:04* f710c07f46da bridge bridge local*08:22:04* 7d05935c9513 host host local*08:22:04* 415e4fd8022f none null local*08:22:04* *08:22:04* *08:22:04* executing shell: docker network rm grid*08:22:04* *08:22:04* Error response from daemon: network grid not found*08:22:04* *08:22:04* executing shell: docker network ls*08:22:04* NETWORK ID NAME DRIVER SCOPE*08:22:04* f710c07f46da bridge bridge local*08:22:04* 7d05935c9513 host host local*08:22:04* 415e4fd8022f none null local*08:22:04* *08:22:04* *08:22:04* executing shell: docker network ls*08:22:04* NETWORK ID NAME DRIVER SCOPE*08:22:04* f710c07f46da bridge bridge local*08:22:04* 7d05935c9513 host host local*08:22:04* 415e4fd8022f none null local*08:22:04* *08:22:04* *08:22:04* creating docker network for grid*08:22:04* executing shell: docker network create grid*08:22:04* 7406c15c141eccac968e5fba9f091d83831a29c92fc9f61b95bc4fba47f5e73f*08:22:04* *Global link to the CQ fail[3]* [1] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chang… [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chang… [3] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chang… -- GALIT ROSENTHAL SOFTWARE ENGINEER Red Hat <https://www.redhat.com/> galit(a)gmail.com T: 972-9-7692230 <https://red.ht/sig>

4 3

[ OST Failure Report ] [ oVirt Master ] [ 07-03-2019 ] [ / 004_basic_sanity.verify_glance_import]
by Galit Rosenthal 07 Mar '19

07 Mar '19

Hi, we are failing basic suite master ( ovirt-engine) It looks a problem in ovirt-engine Can you please have a look at the issue? Thanks, Galit Error [1]: 'NoneType' object has no attribute 'status' -------------------- >> begin captured logging << -------------------- ovirtlago.testlib: ERROR: * Unhandled exception in <function <lambda> at 0x7f5e9feb3ed8> Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 234, in assert_equals_within res = func() File "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/004_basic_sanity.py", line 1153, in <lambda> lambda: api.disks.get(disk_name).status.state == 'ok', AttributeError: 'NoneType' object has no attribute 'status' --------------------- >> end captured logging << ------------- US CQ of the ovirt-engine results can be found [2] We see the same error DS as well [3] [1] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chang… [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chang… [3] https://rhv-devops-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/blue/rest/organi… -- GALIT ROSENTHAL SOFTWARE ENGINEER Red Hat <https://www.redhat.com/> galit(a)gmail.com T: 972-9-7692230 <https://red.ht/sig>

5 9

Please don't remove instance type
by Baptiste Agasse 07 Mar '19

07 Mar '19

Hi all, We are happy oVirt users for some years now (we started with 3.6, now on 4.2) and we manage most of our virtualization stacks with it. To provision and manage our machines, we use the foreman (for bare metal and virtual machines) on top of it. I made some little contributions to the foreman and other underlying stuff to have a deeper integration with oVirt, like to be able to select instance type directly from foreman interface/api and we rely on it. We use instance types to standardize our vms by defining system resources (memory, cpu and cpu topology) console type, boot options. On top of that we plan to use templates to apply OS (CentOS 7 and CentOS 6 actually). Having resources definitions separated from OS installation help us to keep instance types and templates lists small and don't bother users about some technical underlying stuff. As we are interested in automating oVirt maintenance tasks and configuration with ansible, I asked at FOSDEM oVirt booth if there is any ansible module to manage instance types in Ovirt as I didn't find it in ovirt ansible infra repo. The person to whom I asked the question said that you are planning to remove instance types from ovirt, and this make me sad :(. So here I am to ask why do you plan to remove instance types from oVirt. As far as I know, it's fairly common to have "instance types" / "flavors" / "sizes" on one side and then templates (bare OS, preinstalled appliances...) on other side and pick one of each to make an instance. If this first part is missing in future version of ovirt, it will be a pain point for us. So, my question is, do you really plan to remove instances type definitely ? Cheers. -- Baptiste

3 4

Taking down the engine without setting global maintenance
by Yedidyah Bar David 07 Mar '19

07 Mar '19

Hi all, How about making this change: Right before the engine goes down cleanly, it marks the shared storage saying it did not crash but exited cleanly, and then HE-HA will not try to restart it on another host. Perhaps make this optional, so that users can do clean shutdowns and still test HA cleanly (or some other use cases, where users might not want this). This should help a lot cases where people restarted their engine for some reason, e.g. upgrade, and forgot to set maintenance. Makes sense? -- Didi

3 5

How can I set up a newly created virtual machine to use the qcow2 format disk by default
by mask.zan＠gmail.com 06 Mar '19

06 Mar '19

How can I set up a newly created virtual machine to use the qcow2 format disk by default? my ovirt version is 4.3.1

2 1

Which OST suites are run on Jenkins?
by Milan Zamazal 06 Mar '19

06 Mar '19

Hi, where can I find which OST suites are run on Jenkins automatically and when? Thanks, Milan

2 3

getting a weird error when doing OST
by Ahmad Khiet 06 Mar '19

06 Mar '19

Hi, I'm trying to run OST on a patch, but I'm getting the following error: tried twice.. and I'm getting the same error : https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4221/console https://jenkins.ovirt.org/job/ovirt-system-tests_manual/4206/console Thanks, Ahmad. *10:06:27* *10:06:27* - STDERR*10:06:27* ++ uname -r*10:06:27* ++ awk -F. '{print $(NF-1)}'*10:06:27* + DIST=el7*10:06:27* + FC_REGEX='^fc[0-9]+$'*10:06:27* + cat*10:06:27* + cat*10:06:27* ++ ip route*10:06:27* ++ awk '$1=="default" {print $5; exit}'*10:06:27* + NIC=eth0*10:06:27* ++ /sbin/ip -4 -o addr show dev eth0*10:06:27* ++ awk '{split($4,a,"."); print a[1] "." a[2] "." a[3] "." a[4]}'*10:06:27* ++ awk -F/ '{print $1}'*10:06:27* + ADDR=192.168.201.4*10:06:27* + echo '192.168.201.4 engine'*10:06:27* + pkgs_to_install=("ntp" "net-snmp" "ovirt-engine" "ovirt-log-collector" "ovirt-engine-extension-aaa-ldap*" "otopi-debug-plugins" "cronie")*10:06:27* + install_firewalld*10:06:27* + [[ el7 == \e\l\7 ]]*10:06:27* + rpm -q firewalld*10:06:27* + systemctl enable firewalld*10:06:27* + systemctl start firewalld*10:06:27* + [[ el7 == \e\l\7 ]]*10:06:27* + install_cmd='yum install --nogpgcheck --downloaddir=/dev/shm -y'*10:06:27* + yum install --nogpgcheck --downloaddir=/dev/shm -y ntp net-snmp ovirt-engine ovirt-log-collector 'ovirt-engine-extension-aaa-ldap*' otopi-debug-plugins cronie*10:06:27* Error: Package: ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rubygem-fluent-plugin-viaq_data_model*10:06:27* Error: Package: ovirt-engine-setup-plugin-ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rh-postgresql95-postgresql-contrib*10:06:27* Error: Package: ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rubygem-fluent-plugin-rewrite-tag-filter*10:06:27* Error: Package: ovirt-engine-setup-plugin-ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rh-postgresql95-postgresql-server*10:06:27* Error: Package: ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rubygem-fluent-plugin-secure-forward*10:06:27* Error: Package: ovirt-engine-tools-backup-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rh-postgresql95-postgresql*10:06:27* Error: Package: ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rh-postgresql95-postgresql-server*10:06:27* Error: Package: 1:java-1.8.0-openjdk-1.8.0.201.b09-2.el7_6.x86_64 (alocalsync)*10:06:27* Requires: gtk2(x86-64)*10:06:27* Error: Package: ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rh-postgresql95-postgresql-contrib*10:06:27* Error: Package: ovirt-engine-4.3.0-0.2.master.20190303132316.git026851f.el7.noarch (alocalsync)*10:06:27* Requires: rubygem-fluent-plugin-collectd-nest*10:06:27* + ret=1*10:06:27* + echo 'install failed with status 1'*10:06:27* + exit 1*10:06:27* *10:06:27* * [Thread-4] Deploy VM lago-basic-suite-master-engine: ERROR (in 0:00:19)*10:07:41* * [Thread-2] Deploy VM lago-basic-suite-master-host-0: ERROR (in 0:01:34)*10:07:41* # Deploy environment: ERROR (in 0:01:34)*10:07:41* @ Deploy oVirt environment: ERROR (in 0:01:34)*10:07:41* Error occured, aborting*10:07:41* Traceback (most recent call last):*10:07:41* File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 383, in do_run*10:07:41* self.cli_plugins[args.ovirtverb].do_run(args)*10:07:41* File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 184, in do_run*10:07:41* self._do_run(**vars(args))*10:07:41* File "/usr/lib/python2.7/site-packages/lago/utils.py", line 549, in wrapper*10:07:41* return func(*args, **kwargs)*10:07:41* File "/usr/lib/python2.7/site-packages/lago/utils.py", line 560, in wrapper*10:07:41* return func(*args, prefix=prefix, **kwargs)*10:07:41* File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 181, in do_deploy*10:07:41* prefix.deploy()*10:07:41* File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, in wrapper*10:07:41* return func(*args, **kwargs)*10:07:41* File "/usr/lib/python2.7/site-packages/ovirtlago/reposetup.py", line 127, in wrapper*10:07:41* return func(*args, **kwargs)*10:07:41* File "/usr/lib/python2.7/site-packages/ovirtlago/prefix.py", line 284, in deploy*10:07:41* return super(OvirtPrefix, self).deploy()*10:07:41* File "/usr/lib/python2.7/site-packages/lago/sdk_utils.py", line 50, in wrapped*10:07:41* return func(*args, **kwargs)*10:07:41* File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 636, in wrapper*10:07:41* return func(*args, **kwargs)*10:07:41* File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 1671, in deploy*10:07:41* self.virt_env.get_vms().values()*10:07:41* File "/usr/lib/python2.7/site-packages/lago/utils.py", line 103, in invoke_in_parallel*10:07:41* return vt.join_all()*10:07:41* File "/usr/lib/python2.7/site-packages/lago/utils.py", line 57, in _ret_via_queue*10:07:41* queue.put({'return': func()})*10:07:41* File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 1662, in _deploy_host*10:07:41* host.name(),*10:07:41* LagoDeployError: /dev/shm/ost/deployment-basic-suite-master/default/scripts/_home_jenkins_workspace_ovirt-system-tests_manual_ovirt-system-tests_basic-suite-master_deploy-scripts_setup_engine.sh failed with status 1 on lago-basic-suite-master-engine

2 1

oVirt documentation vs. feature pages
by Greg Sheremeta 05 Mar '19

05 Mar '19

Hi, TL;DR: please don't direct users to feature pages -- direct them to end-user documentation instead. And maintain content separation between end-user documentation and technical docs like feature pages. ... Lately we've cleaned up documentation on ovirt.org, and I wanted to share some of my thoughts about it. As a user experience focused person, I really believe that clear and helpful documentation is crucial to the project's success. I've also seen outdated documentation be a source of extreme frustration for our users. In the distant past, most of oVirt's documentation was written by developers on a wiki, typically in the form of "feature pages." Feature pages are basically technical design documents with occasionally some user help sprinkled in. With oVirt 4.0, we put a great set of clear documentation, written by technical writers, on the oVirt website (which was also converted from a wiki to a regular static site). This documentation is up to date with 4.2, and we'll get the 4.3 content out there soon. This official documentation lives at https://ovirt.org/documentation and it should be considered the authoritative place for users to access our documentation. Feature pages, on the other hand, are (now) for developers. When you hear the term "feature page", think "technical design document." Most users should not be interested in this content. It helps to think about the personas. 1. oVirt admins -- the person who sets up oVirt on Day 1 and 2. This is the person who cares about and will read the Installation Guide and the Administration Guide. These live under /documentation, e.g. https://ovirt.org/documentation/install-guide/Installation_Guide.html 2. oVirt users -- the people who use oVirt to create, manage, and use virtual machines, etc. This person will care about and read the VM Portal Guide, User Guides, and such. These also live under /documentation, e.g. https://ovirt.org/documentation/vmm-guide/Virtual_Machine_Management_Guide.… 3. Developers -- you and I, and occasionally highly curious and technical admins. These people might care about how the project works under the hood -- high level designs, code flows, etc. Persona 2, oVirt users, do not care about these details when they are learning to use oVirt, so end-user documentation should not be polluted with this type of content. This content now lives exclusively under /develop, the developer's section of the site. https://ovirt.org/develop/release-management/features/ Let's help our users by directing them to the end-user documentation, not to feature pages. If you would like to contribute end-user documentation, it should go under /documentation and not in a feature page. If you build a new feature, the technical stuff goes under /develop/release-management/features/ and the end-user stuff goes under /documentation. Feedback welcome :) Best wishes, Greg -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme(a)redhat.com IRC: gshereme <https://red.ht/sig>

4 5

[URGENT] gluster-anisble dependency disappeared from copr repository
by Sandro Bonazzola 05 Mar '19

05 Mar '19

Hi, with https://gerrit.ovirt.org/#/c/97730/ a dependency on gluster-ansible package from sac/gluster-ansible copr repository has been introduced. Such package is not available anymore causing breakage at oVirt Node build time. Please fix gluster ansible packaging as soon as possible for properly handling upgrade for those who already installed gluster-ansible and fix the requirements for oVirt node builds. Thanks -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 3

Updating Fedora 28 fail with "Package glusterfs-5.4-1.fc28.x86_64.rpm is not signed"
by Nir Soffer 05 Mar '19

05 Mar '19

# dnf update ... Package glusterfs-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-libs-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-server-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-fuse-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-devel-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-api-devel-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-api-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-cli-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-client-xlators-5.4-1.fc28.x86_64.rpm is not signed Package glusterfs-extra-xlators-5.4-1.fc28.x86_64.rpm is not signed Package python3-gluster-5.4-1.fc28.x86_64.rpm is not signed The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: GPG check FAILED This is a development laptop and I never installed or need glusterfs-server. I could remove glusterfs-server, but other glusterfs packages seems to be required by libvirt, libguestfs and qemu. I tried "dnf clean all" and removed yum/dnf caches, but it does not help. In the meantime I could update by excluding glusterfs. I hope someone has a better solution. Nir

2 2

Re: [JIRA] (OVIRT-2566) make network suite blocking
by Nir Soffer 04 Mar '19

04 Mar '19

On Mon, Nov 5, 2018 at 8:59 AM danken (oVirt JIRA) < jira(a)ovirt-jira.atlassian.net> wrote: > danken created OVIRT-2566: > ----------------------------- > > Summary: make network suite blocking > Key: OVIRT-2566 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-2566 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: OST > Reporter: danken > Assignee: infra > Priority: High > > > The network suite is executing nightly for almost a year. It has a caring > team that tends to it, and it does not have false positives. > Currently, it currently fails for a week on the 4.2 branch, but it is due > to a production code bug. > > https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… > > I would like to see this suite escalated to the importance of the basic > suite, making it a gating condition for marking a collection of packages as > "tested". > I'm ok with this only if it will gate *only* vdsm-network package, and it will run in parallel, so it does not slow down OST run. For basic suite, we have too many random failures, so I don't think it is useful, and we should make it optional. Nir > > [~gbenhaim(a)redhat.com] what should be done to make this happen? > > > > > -- > This message was sent by Atlassian Jira > (v1001.0.0-SNAPSHOT#100095) > _______________________________________________ > Infra mailing list -- infra(a)ovirt.org > To unsubscribe send an email to infra-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/infra@ovirt.org/message/VFQ776FLS2QBA… >

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.2)
by Tal Nisan 04 Mar '19

04 Mar '19

1 0

vdsm has been tagged (v4.30.10)
by Milan Zamazal 04 Mar '19

04 Mar '19

1 0

vdsm Check-patch failed - ERROR: Error fetching remote repo 'origin'
by Eyal Shenitzky 04 Mar '19

04 Mar '19

Hey, I saw the following error on the vdsm check-patch: *09:47:31* ERROR: Error fetching remote repo 'origin'*09:47:31* hudson.plugins.git.GitException: Failed to fetch from https://gerrit.ovirt.org/vdsm*09:47:31* at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:904)*09:47:31* at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1144)*09:47:31* at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1175)*09:47:31* at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:120)*09:47:31* at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:90)*09:47:31* at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:77)*09:47:31* at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)*09:47:31* at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)*09:47:31* at java.util.concurrent.FutureTask.run(FutureTask.java:266)*09:47:31* at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)*09:47:31* at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)*09:47:31* at java.lang.Thread.run(Thread.java:748)*09:47:31* Caused by: hudson.plugins.git.GitException: Command "git clean -fdx" returned status code 1:*09:47:31* stdout: *09:47:31* stderr: warning: failed to remove .tox/lib-py27/lib/python2.7/site-packages/pytest_cov/__pycache__/plugin.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove .tox/lib-py27/lib/python2.7/site-packages/pytest_cov/__pycache__/compat.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove .tox/lib-py27/lib/python2.7/site-packages/pytest_cov/__pycache__/engine.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove .tox/lib-py27/lib/python2.7/site-packages/pytest_cov/__pycache__/embed.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove tests/__pycache__/pywatch_test.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove tests/__pycache__/prlimit_test.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove tests/__pycache__/ssl_test.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove tests/__pycache__/hooking_test.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove tests/common/__pycache__/systemd_test.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove tests/common/__pycache__/systemctl_test.cpython-27-PYTEST.pyc: Permission denied*09:47:31* warning: failed to remove tests/common/__pycache__/commands_test.cpython-27-PYTEST.pyc: Permission denied*09:47:31* Does someone encounter it? -- Regards, Eyal Shenitzky

2 4

Can't discover luns on iscisi target when host is running fedora 28
by Fedor Gavrilov 04 Mar '19

04 Mar '19

Hi, Recently I hit an issue when I can't add iscsi storage domain because engine can't see any LUNs there. I wonder if I missed some step in the configuration or something. There is a fedora 29 machine running iscsi target which has a single lun and host (banana) registered in its ACL: [cucumber@cucumber ~]$ sudo targetcli [sudo] password for cucumber: targetcli shell version 2.1.fb48 Copyright 2011-2013 by Datera, Inc and others. For help on commands, type 'help'. /iscsi/iqn.20...e:target/tpg1> ls o- tpg1 ..................................................................................................... [no-gen-acls, no-auth] o- acls ................................................................................................................ [ACLs: 1] | o- iqn.1994-05.com.redhat:4bf5ff1a15b6 ........................................................................ [Mapped LUNs: 1] | o- mapped_lun0 ................................................................................. [lun0 fileio/filestore0 (rw)] o- luns ................................................................................................................ [LUNs: 1] | o- lun0 ................................................................... [fileio/filestore0 (/etc/fileio) (default_tg_pt_gp)] o- portals .......................................................................................................... [Portals: 1] o- 0.0.0.0:3260 ........................................................................................................... [OK] From fedora 28 host I can login and logout, but there is this segfault and when I try getting LUN info it fails: [banana@banana ~]$ sudo iscsiadm --mode discovery --type sendtargets --portal cucumber 192.168.111.4:3260,1 iqn.2016-01.com.example:target [banana@banana ~]$ sudo iscsiadm -m node -T iqn.2016-01.com.example:target -l Logging in to [iface: default, target: iqn.2016-01.com.example:target, portal: 192.168.111.4,3260] (multiple) Login to [iface: default, target: iqn.2016-01.com.example:target, portal: 192.168.111.4,3260] successful. [banana@banana ~]$ sudo iscsiadm -m session -P 3 -r 2 iscsiadm: could not read session targetname: 5 iscsiadm: Could not get session info for sid 2 [banana@banana ~]$ sudo iscsiadm -m session -P 3 iSCSI Transport Class version 2.0-870 version 6.2.0.874 Segmentation fault It seems I am hitting this: https://bugzilla.redhat.com/show_bug.cgi?id=1462767 Could this be the reason that there are no LUNs in engine web UI after I discover iscsi target? Is anyone aware of workaround or whether I am doing something wrong? Thanks, Fedor Gavrilov

2 2

v2v_conversion_host jenkins job bugged
by Sandro Bonazzola 02 Mar '19

02 Mar '19

Hi, just noticed today we have a jenkins job: https://jenkins.ovirt.org/job/oVirt_v2v-conversion-host_standard-on-ghpush/… which generates packages named like: v2v-conversion-host-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.src.rpm v2v-conversion-host-1.11.0.tar.gz v2v-conversion-host-ansible-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.noarch.rpm v2v-conversion-host-debugsource-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.x86_64.rpm v2v-conversion-host-provider-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.x86_64.rpm v2v-conversion-host-provider-debuginfo-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.x86_64.rpm v2v-conversion-host-wrapper-1.11.0-0.oVirt_v2v_conversion_host_standard_on.githpush_13.20190301133957.fc27.noarch.rpm which are breaking NVR naming conventions for RPMs and are probably the result of a bug within jenkins job. Please fix the job as soon as possible and clean up - https://resources.ovirt.org/repos/ovirt/tested/master - https://resources.ovirt.org/repos/ovirt/tested/4.2 - https://resources.ovirt.org/pub/ovirt-4.2-snapshot - https://resources.ovirt.org/pub/ovirt-master-snapshot Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 1

Re: [Vdo-devel] impact of --emulate512 setting for VDO volumes
by Guillaume Pavese 02 Mar '19

02 Mar '19

Thank you very much for your answer. I am copying ovirt-devel too as that could be of interest to them. Guillaume Pavese Ingénieur Système et Réseau Interactiv-Group On Sat, Mar 2, 2019 at 7:00 AM Michael Sclafani <sclafani(a)redhat.com> wrote: > Hi! > > 512 emulation was intended to support drivers that only do a fraction of > their I/O in blocks smaller 4KB. It is not optimized for performance in any > way. Under the covers, VDO is still operating on 4KB physical blocks, so > each 512-byte read is potentially amplified to a 4KB read, and each > 512-byte write to a 4KB read followed by a 4KB write. A workload consisting > exclusively of 512-byte randomly-distributed writes could effectively be > amplified by a factor of 16. > > We have a suite of automated tests we run in 512e mode on a nightly basis. > That suite is a subset of our regular tests, containing only ones we expect > would be likely to expose problems specific to the emulation. > > There should be no penalty to having emulation enabled on a volume that no > longer uses it. If the I/O is 4KB-aligned and 4KB or larger, having it > enabled won't affect it. > It does not appear the setting can be modified by the VDO manager, but I > cannot remember at this moment why that should be so. > > Hope this helps. > > On Fri, Mar 1, 2019 at 2:24 PM Guillaume Pavese < > guillaume.pavese(a)interactiv-group.com> wrote: > >> Hello, >> >> We are planning to deploy VDO with oVirt 4.3 on centos 7.6 (on SSD >> devices). >> As oVirt does not support 4K devices yet, VDO volumes are created with >> the parameter "--emulate512 enabled" >> >> What are the implications of this setting? Does it impact performance? If >> so, is it IOPS or throughput that is impacted? What about reliability (is >> that mode equally tested as standard mode)? >> >> As I saw on RH Bugzilla, support for 4K devices in oVirt will need to >> wait at least for Centos 7.7 >> Once that is supported, would it be possible to transition/upgrade an >> emulate512 vdo volume to a standard one? >> >> Thanks, >> >> Guillaume Pavese >> Ingénieur Système et Réseau >> Interactiv-Group >> _______________________________________________ >> Vdo-devel mailing list >> Vdo-devel(a)redhat.com >> https://www.redhat.com/mailman/listinfo/vdo-devel >> >

1 0

[RHV] [CQ weekly status] [01-03-2019]
by Dafna Ron 01 Mar '19

01 Mar '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-RHV-4.2:* GREEN (#1) Last failure was on 28-02-2019 for project rhevm-appliance due to a failed build-artifacts job. this issue is still happening and message was sent to developer. *CQ-RHV-Master:* GREEN (#1) Last failure is identical to 4.2 - build-artifacts for the same project. ** We do not yet have a 4.3 CQ job which we will start working on next week. Current running jobs for 4.2 [1] and for master [2] can be found below: [1] https://rhv-devops-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Change%20qu… [2] https://rhv-devops-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Change%20qu… Happy week! Dafna ------------------------------------------------------------------------------------------------------------------------ COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2)

1 0

[Ovirt] [CQ weekly status] [01-03-2019]
by Dafna Ron 01 Mar '19

01 Mar '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#1) Last CQ job failure on 4.2 was 27-02-2019 on project ovirt-provider-ovn due to a failed build-artifacts job. this issue is now fixed. Please note that this is a CQ job failure but not an OST job failure as we exit if no package is available. *CQ-4.3*: RED (#1) We added a CQ job for 4.3 but not all projects created the branch yet. I created a google sheet to follow the advancement of this work and I will use this report to ask all the managers to go over the doc and add info: https://docs.google.com/spreadsheets/d/1i142cTN_0QwOvogtlQiF6bcIYxTpBqYBed2… *CQ-Master:* RED (#1) We have sporadic failures in test get_host_devices this is effecting all projects and we have yet to know what is causing the issue. Michal checked the issue and thinks the test should be modified to do a re-try as the info is filled by the host 4 seconds after the query is sent. Milan was asked to add a loop with 1s delay to get_host_devices to fix the test. Please note that we have ruled out a possible infra cause for this failure before alerting dev as the failure is sporadic and happens on multiple projects. Jira: https://ovirt-jira.atlassian.net/browse/OVIRT-2686 Current running jobs for 4.2 [1] and master [2] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… Happy week! Dafna ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3)

1 0

[ OST Failure Report ] [ oVirt Master ] [ 27-02-2019 ] [ 002_bootstrap.get_host_devices]
by Galit Rosenthal 01 Mar '19

01 Mar '19

Hi, we are failing basic suite master (vdsm, ovirt-engine-sdk ...) It happens sporadically. We disqualify that this is an infra issue. Can you please have a look at the issue? ERROR: <testcase classname="002_bootstrap" name="get_host_devices" time="0.077"> <error type="exceptions.RuntimeError" message="*Could not find block_vda_1 device in host devices*: "><![CDATA[Traceback (most recent call last): File "/usr/lib64/python2.7/unittest/case.py", line 369, in run testMethod() File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 142, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 60, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 79, in wrapper prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs File "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py", line 1016, in get_host_devices raise RuntimeError('Could not find block_vda_1 device in host devices: {}'.format(device_list)) RuntimeError: Could not find block_vda_1 device in host devices: ]]></error> Thanks, Galit Examples, Full logs: [1] https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/ovirt-m… [2] https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/ovirt-m… _______________________________________________ Infra mailing list -- infra(a)ovirt.org To unsubscribe send an email to infra-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/infra@ovirt.org/message/WXW6II3NYEXHI… -- GALIT ROSENTHAL SOFTWARE ENGINEER Red Hat <https://www.redhat.com/> galit(a)gmail.com T: 972-9-7692230 <https://red.ht/sig>

9 14

unboundid-ldapsdk-4.0.9 is now available for testing
by Sandro Bonazzola 01 Mar '19

01 Mar '19

On Fedora we had previously 4.0.7. The new releases 4.0.7 will be soon available within repositories for Fedora >= 30 and includes several bug fixes and enhancements. You can see release notes for 4.0.8 and 4.0.9 here: https://github.com/pingidentity/ldapsdk/releases In oVirt this package is required by ovirt-engine-extension-aaa-ldap. If you're going to test the package, please provide feedback here. Martin, Ravi, let me know if you see value in backporting this version to Fedora 28 and EL7 for oVirt 4.3 consumption. Thanks, -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

[NOTICE] infra issue in progress in jenkins
by Dafna Ron 01 Mar '19

01 Mar '19

Hi, We had a job fail due to a failure in yum. it seems yum is searching for repodata in a wrong location. Evgheni is currently working to investigate and fix the problem and will update soon Jira opened: https://ovirt-jira.atlassian.net/browse/OVIRT-2689 Thanks, Dafna

1 1