- Devel - oVirt List Archives

Installing vdsm on f27
by Piotr Kliczewski 26 Apr '18

26 Apr '18

All, I attempted to install vdsm on my f27 machine but I failed due to missing dependency. I was unable to find rubygem-fluent-plugin-elasticsearch. I used upstream repos and was not able to find it. From where a user can get it? Thanks, Piotr

4 3

[ OST Failure Report ] [ oVirt 4.2 ] [ 2018-04-04 ] [006_migrations.prepare_migration_attachments_ipv6]
by Barak Korren 26 Apr '18

26 Apr '18

Test failed: [ 006_migrations.prepare_migration_attachments_ipv6 ] Link to suspected patches: (Probably unrelated) https://gerrit.ovirt.org/#/c/89812/1 (ovirt-engine-sdk) - examples: export template to an export domain This seems to happen multiple times sporadically, I thought this would be solved by https://gerrit.ovirt.org/#/c/89781/ but it isn't. Link to Job: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1537/ Link to all logs: http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1537/artifact/ex… Error snippet from log: <error> 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 129, in wrapped_test test() File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 59, in wrapper return func(get_test_prefix(), *args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 78, in wrapper prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs File "/home/jenkins/workspace/ovirt-4.2_change-queue-tester/ovirt-system-tests/basic-suite-4.2/test-scenarios/006_migrations.py", line 139, in prepare_migration_attachments_ipv6 engine, host_service, MIGRATION_NETWORK, ip_configuration) File "/home/jenkins/workspace/ovirt-4.2_change-queue-tester/ovirt-system-tests/basic-suite-4.2/test_utils/network_utils_v4.py", line 71, in modify_ip_config check_connectivity=True) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 36729, in setup_networks return self._internal_action(action, 'setupnetworks', None, headers, query, wait) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 299, in _internal_action return future.wait() if wait else future File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 55, in wait return self._code(response) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 296, in callback self._check_fault(response) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 132, in _check_fault self._raise_error(response, body) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 118, in _raise_error raise error Error: Fault reason is "Operation Failed". Fault detail is "[Network error during communication with the Host.]". HTTP response code is 400. </error> -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

14 38

Name resolution not working after vdsm installation
by Piotr Kliczewski 25 Apr '18

25 Apr '18

All, I am using latest engine and vdsm 4.20.23-1. I installed vdsm on centos7 vm and after the installation my vm stopped resolving names. Here is my nic configuration before installation: TYPE="Ethernet" BOOTPROTO="dhcp" DEFROUTE="yes" PEERDNS="yes" PEERROUTES="yes" IPV4_FAILURE_FATAL="no" IPV6INIT="yes" IPV6_AUTOCONF="yes" IPV6_DEFROUTE="yes" IPV6_PEERDNS="yes" IPV6_PEERROUTES="yes" IPV6_FAILURE_FATAL="no" NAME="eth0" UUID="0079668a-8708-46ad-8dbf-da418ae6f77e" DEVICE="eth0" ONBOOT="yes" here is after: # Generated by VDSM version 4.20.23-1.el7.centos DEVICE=eth0 BRIDGE=ovirtmgmt ONBOOT=yes MTU=1500 DEFROUTE=no NM_CONTROLLED=no IPV6INIT=no and the bridge: # Generated by VDSM version 4.20.23-1.el7.centos DEVICE=ovirtmgmt TYPE=Bridge DELAY=0 STP=off ONBOOT=yes BOOTPROTO=dhcp MTU=1500 DEFROUTE=yes NM_CONTROLLED=no IPV6INIT=yes DHCPV6C=yes IPV6_AUTOCONF=no Thanks, Piotr

3 5

[ OST Failure Report ] [ oVirt 4.2 (ovirt-engine-metrics) ] [ 25-04-2018 ] [005_network_by_label.assign_hosts_network_label ]
by Dafna Ron 25 Apr '18

25 Apr '18

hi, we have a failure for test 005_network_by_label.assign_hosts_network_label on basic suite. action seemed to have failed because we failed to acquire lock for host The failure does not seem to be related to the reported change *Link and headline of suspected patches: The change reported is not related to *this failure. *Link to Job:* *http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1797/ <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1797/>Link to all logs:http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1797/artifa… <http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1797/artifact/ex…>(Relevant) error snippet from the log: <error>2018-04-25 07:54:13,518-04 WARN [org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand] (default task-19) [69ada7e2] Validation of action 'HostSetupNetworks' failed for user admin@internal-authz. Reasons: VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,ACTION_TYPE_FAILED_SETUP_NETWORKS_OR_REFRESH_IN_PROGRESS2018-04-25 07:54:13,530-04 DEBUG [org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall] (default task-19) [69ada7e2] Compiled stored procedure. Call string is [{call get_entity_snapshot_by_command_id(?)}]2018-04-25 07:54:13,530-04 DEBUG [org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall] (default task-19) [69ada7e2] SqlCall for procedure [get_entity_snapshot_by_command_id] compiled2018-04-25 07:54:13,543-04 ERROR [org.ovirt.engine.core.bll.network.host.LabelNicCommand] (default task-19) [69ada7e2] Transaction rolled-back for command 'org.ovirt.engine.core.bll.network.host.LabelNicCommand'.2018-04-25 07:54:13,548-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-19) [69ada7e2] method: get, params: [d8c9cedc-c26c-45c9-a9fa-78569a96e5da], timeElapsed: 3ms2018-04-25 07:54:13,552-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-19) [69ada7e2] EVENT_ID: LABEL_NIC_FAILED(1,137), Failed to label network interface card eth0 with label NETWORK_LABEL on host lago-basic-suite-4-2-host-1.2018-04-25 07:54:13,552-04 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-19) [69ada7e2] method: runAction, params: [LabelNic, LabelNicParameters:{commandId='97cd3097-83e5-468b-80db-1db341fd6b20', user='null', commandType='Unknown'}], timeElapsed: 57ms2018-04-25 07:54:13,560-04 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-19) [] Operation Failed: [Cannot add Label. Another Setup Networks or Host Refresh process in progress on the host. Please try later.]</error>*

1 0

oVirt Engine 4.2.3 was branched
by Tal Nisan 25 Apr '18

25 Apr '18

We've started Engine's 4.2.3.3 build a couple of hours ago, as discussed in the build meeting since we are close to GA date with only blockers to make to 4.2.3 and a lot of patches queuing up for 4.2.4 I've branched the 4.2.3.z branch. 4.2.4 patches should be backported to ovirt-engine-4.2 branch and will be merged upon receiving the necessary acks and will be included in the upcoming 4.2.4 build. 4.2.3 patches should be backported to ovirt-engine-4.2 branch as well as the ovirt-engine-4.2.3.z branch, the cherry-pick will most likely be cut and clear but in any case of differentiation in the cherry-pick make sure you verify by compiling as well as *no CI is configured for the 4.2.3.z branch.* Tal.

1 0

Issues on master with releasing a lock
by Ravi Shankar Nori 25 Apr '18

25 Apr '18

Hi All, We have some issues with a few flows on master where the lock acquired is being released more than once. This could be a real problem in cases where the lock is prematurely released for a second command that had acquired the lock which the first command has released. For instance 1. Command A has acquired the VM lock and executes a child command. 2. The child command releases the lock 3. Command B now acquires the VM lock 4. Command A continues execution and finally releases the lock the second time 5. The Command B's lock has now been released prematurely by Command A. The tell tale sign indicating that a flow is one of the offending flows is the warning message in the logs indicating that a previously released lock is being released again. [org.ovirt.engine.core.bll.lock.InMemoryLockManager] (EE-ManagedThreadFactory-engine-Thread-6) [1435f925] Trying to release exclusive lock which does not exist, lock key: '53cfa6c3-ecd6-4796-84cb-5c53d7c2a77fVDS_FENCE' I have seen issues with Live Merge [1], Moving storage domain to maintenance[2] , VdsNotRespondingTreatmentCommand [3] and Creating a snapshot [4]. I have submitted some patches to fix the issue with Live Merge [5], Moving storage domain to maintenance [6] and VdsNotRespondingTreatmentCommand [7]. The multiple lock release issue needs to fixed and if you are the owner of a flow please make sure the flow does not log a warning message to the logs. There is no single solution to fix the issue, this has be done flow by flow. But below are a few pointers 1. If a command has a callback and the command is executing a child command, which in turn is executing a few child commands. The child command should also have a command callback so that the locks are released by the framework. Example patch [6] 2. If a parent has acquired the lock and is executing a child command with cloned context, to make sure that the child does not release the locks acquired by the parent pass the cloned parent context with out locks to the child. Example patch [7] Thanks Ravi [1] https://bugzilla.redhat.com/1568556 [2] https://bugzilla.redhat.com/1568447 [3] https://bugzilla.redhat.com/1571300 [4] https://bugzilla.redhat.com/1569625 <https://bugzilla.redhat.com/1569625> [5] https://gerrit.ovirt.org/#/c/90482/ [6] https://gerrit.ovirt.org/#/c/90411/ [7] https://gerrit.ovirt.org/#/c/90568/

2 1

Invitation: oVirt STDCI v2 deep dive @ Thu Apr 26, 2018 11:00 - 12:00 (IDT) (devel@ovirt.org)
by bkorren＠redhat.com 24 Apr '18

24 Apr '18

You have been invited to the following event. Title: oVirt STDCI v2 deep dive Introduction to the 2nd version of oVirt's CI standard - What is it, what can it do, how to use it and how does it work. BJ link: https://bluejeans.com/8705030462 When: Thu Apr 26, 2018 11:00 – 12:00 Jerusalem Where: raanana-04-asia-8-p-vc; https://bluejeans.com/8705030462 Calendar: devel(a)ovirt.org Who: * bkorren(a)redhat.com - organizer * devel(a)ovirt.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=MHBvcmNoYWQ5YmtzNmlmd… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account devel(a)ovirt.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 7

Updated invitation: oVirt STDCI v2 deep dive @ Thu May 3, 2018 11:00 - 12:00 (IDT) (devel@ovirt.org)
by bkorren＠redhat.com 24 Apr '18

24 Apr '18

This event has been changed. Title: oVirt STDCI v2 deep dive Introduction to the 2nd version of oVirt's CI standard - What is it, what can it do, how to use it and how does it work. Note: Meeting was moved To join the Meeting: https://bluejeans.com/8705030462 To join via Room System: Video Conferencing System: redhat.bjn.vc -or-199.48.152.18 Meeting ID : 8705030462 To join via phone : 1) Dial: 408-915-6466 (United States) (see all numbers - https://www.redhat.com/en/conference-numbers) 2) Enter Conference ID : 8705030462 RSVP at: https://www.eventbrite.com/e/ovirt-stdci-v2-deep-dive-tickets-45468120372 (changed) When: Thu May 3, 2018 11:00 – 12:00 Jerusalem (changed) Where: ; https://bluejeans.com/8705030462, raanana-04-asia-8-p-vc (changed) Calendar: devel(a)ovirt.org Who: * bkorren(a)redhat.com - organizer * devel(a)ovirt.org * sbonazzo(a)redhat.com * dkenigsb(a)redhat.com * rbarry(a)redhat.com * mskrivan(a)redhat.com * eedri(a)redhat.com * tjelinek(a)redhat.com * tnisan(a)redhat.com * mperina(a)redhat.com * sradco(a)redhat.com * msivak(a)redhat.com * sabose(a)redhat.com Event details: https://www.google.com/calendar/event?action=VIEW&eid=MHBvcmNoYWQ5YmtzNmlmd… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account devel(a)ovirt.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

Vdsm: Intent to create ovirt-4.2.3 branch
by Milan Zamazal 23 Apr '18

23 Apr '18

Hi, since oVirt 4.2.3 has been stabilizing, we will make ovirt-4.2.3 Vdsm branch in a couple of days, once the next tag is created. This is in accordance with the stable branch policy outlined and proposed by Francesco[1]. Until the next Vdsm tag is created, we accept only Vdsm patches intended for oVirt 4.2.3 to ovirt-4.2 branch. After the next tag is created, we'll make separate ovirt-4.2.3 branch and accept all qualified Vdsm patches to ovirt-4.2 again. Then Vdsm patches for 4.2.3 must be additionally backported to the newly created ovirt-4.2.3 branch. Thanks, Milan Footnotes: [1] http://lists.ovirt.org/pipermail/devel/2018-March/032820.html

1 0

OST ha_recovery test failing
by Greg Sheremeta 23 Apr '18

23 Apr '18

I'm seeing this fail periodically on a patch I'm working on, and it's not related to my work. Any ideas? <testcase classname="004_basic_sanity" name="ha_recovery" time="1058.886"> <failure type="exceptions.AssertionError" message="False != True after 600 seconds... tests/basic-suite-master/test-scenarios/004_basic_sanity.py", line 735, in ha_recovery lambda: File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 271, in assert_true_within_long assert_equals_within_long(func, True, allowed_exceptions) File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 258, in assert_equals_within_long func, value, LONG_TIMEOUT, allowed_exceptions=allowed_exceptions File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 237, in assert_equals_within '%s != %s after %s seconds' % (res, value, timeout) 'False != True after 600 seconds http://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/363/ar… -- 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>

3 2