oVirt STDCI v2 deep dive
by bkorren＠redhat.com
Please note that the talk was re-scheduled after it was initially announced.
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.
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
When: Thu May 3, 2018 11:00 – 12:00 Jerusalem
Where: ; https://bluejeans.com/8705030462, raanana-04-asia-8-p-vc
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
6 years
Installing vdsm on f27
by Piotr Kliczewski
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
6 years
[ OST Failure Report ] [ oVirt 4.2 ] [ 2018-04-04 ] [006_migrations.prepare_migration_attachments_ipv6]
by Barak Korren
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/...
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
6 years
Name resolution not working after vdsm installation
by Piotr Kliczewski
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
6 years
[ OST Failure Report ] [ oVirt 4.2 (ovirt-engine-metrics) ] [ 25-04-2018 ] [005_network_by_label.assign_hosts_network_label ]
by Dafna Ron
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/arti...
<http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1797/artifact/...>(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>*
6 years
oVirt Engine 4.2.3 was branched
by Tal Nisan
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.
6 years
Issues on master with releasing a lock
by Ravi Shankar Nori
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/
6 years
