Vdsm: Intent to create ovirt-4.2.3 branch
by Milan Zamazal
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
5 years, 12 months
OST ha_recovery test failing
by Greg Sheremeta
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/...
--
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>
5 years, 12 months
Removing validateQemuReadable check
by Andrew DeMaria
Hi all,
I am using ovirt with an nfs server that enforces sec=krb5p. To do so, I
have created a service account of a sort for ovirt to use when accessing
the kerberized nfs server. Things seem to work pretty well except for the
the ISO storage domain. After adding an ISO image, it does not show in the
storage domain. The problem is the following check when searching for iso
files within the nfs mount:
def validateQemuReadable(self, targetPath):
"""
Validate that qemu process can read file
"""
gids = (grp.getgrnam(constants.DISKIMAGE_GROUP).gr_gid,
grp.getgrnam(constants.METADATA_GROUP).gr_gid)
st = _IOProcessOs(self._iop).stat(targetPath)
if not (st.st_gid in gids and st.st_mode & stat.S_IRGRP or
st.st_mode & stat.S_IROTH):
raise OSError(errno.EACCES, os.strerror(errno.EACCES))
Although my vdsm and qemu user can read and write to the iso file, this
check fails as the file is not group owned by either, but by my service
account:
-bash-4.2$ whoami
vdsm
-bash-4.2$ sha256sum Fedora-Workstation-netinst-x86_64-27-1.6.iso
18ef4a6f9f470b40bd0cdf21e6c8f5c43c28e3a2200dcc8578ec9da25a6b376b
Fedora-Workstation-netinst-x86_64-27-1.6.iso
-bash-4.2$ touch Fedora-Workstation-netinst-x86_64-27-1.6.iso
-bash-4.2$ ls -alh Fedora-Workstation-netinst-x86_64-27-1.6.iso
-rw-r-----. 1 autovirt autovirt 508M Apr 22 20:31
Fedora-Workstation-netinst-x86_64-27-1.6.iso
-bash-4.2$ klist
Ticket cache: KEYRING:persistent:36:36
Default principal: autovirt(a)SOMEDOMAIN.NET
Valid starting Expires Service principal
04/22/2018 20:03:57 04/23/2018 20:03:57 krbtgt/
SOMEDOMAIN.NET(a)SOMEDOMAIN.NET
After modifying the validateQemuReadable functions (fileUtils.py and
outOfProcess.py) to be a noop return True, the ISO file showed up and I was
able to use it in a VM.
Would a patch be considered to remove this validateQemuReadable check? As
shown above, the current implementation causes more harm than good. I'd
rather for non readable ISO files to show up in the list and get a failure
during VM runtime anyways.
Thanks,
Andrew
5 years, 12 months
Disabling STDCI V1 OST jobs
by Daniel Belenky
Hello,
You might have noticed that in the last two weeks, you see a new job
reporting when sending a patch to OST
called "*ovirt-system-tests_standard-check-patch*". This is an STDCI V2
based check-patch job for OST.
We have tested it in the past 2.5 weeks on OST project to ensure the
reporting is correct and accurate.
We've now come to a point where we will disable the old job in favor of the
new one.
*How it will affect you when sending a patch to OST:*
The major advantage of STDCI V2 is the ability to run tasks in *parallel*.
We utilize this feature in OST to run all
the suites that were affected by your change in parallel. It means that
patches that change some common file
that triggers 4 suites, should finish checking now within ~30-40 min
instead of ~2 hours.
Another advantage of STDCI V2 based job is that in case of a failure in a
particular suite, we keep running the
rest of the suites, so when the job finishes, by looking at the results we
already know exactly which suites were
affected and which are still working (unlike in STDCI V1 where the first
failing suite would have failed the entire
job).
*Note:* suites will run in parallel on different nodes, so they won't
affect each others environment.
*How to debug:*
*Logs location*
All suite logs are still collected as they used to, and located under
*exported-artifacts/check-patch.{suite-name}.el7.x86_64*.
*Blue ocean view*
You can now see a graphical representation of the suites running in
parallel for your change.
At the left side menu in your check-patch job, click on "*Open Blue Ocean*"
Loading may take few seconds.
Let STDCI compute the relevant suites for your patch, and start running
them:
If you want to download the *console output* from a certain suite, press
the circle above the suite's name
in "Blue Ocean" view, and below the graph view, you can find the following
icons:
The right rectangle will open a new window with the job's console output
and be pressing the arrow you can
download it.
If any questions will raise, please feel free contacting OST team directly
or by opening a ticket by sending an email
to infra-support(a)ovirt.org.
--
DANIEL BELENKY
RHV DEVOPS
5 years, 12 months
OST failure: 002_bootstrap.configure_high_perf_vm2
by Milan Zamazal
Hi, I experienced the following OST failure on my OST patch:
http://jenkins.ovirt.org/job/ovirt-system-tests_master_check-patch-el7-x8...
The failure is unrelated to my patch, since it occurred before reaching
its changes. OST passed when I retriggered it later.
The error was:
2018-04-20 05:08:46,748-04 WARN [org.ovirt.engine.core.bll.numa.vm.AddVmNumaNodesCommand] (default task-6) [a8a3d723-655c-43ba-9776-70eb9317e66c] Validation of action 'AddVmNumaNodes' failed for user admin@internal-authz. Reasons: ACTION_TYPE_FAILED_VM_PINNED_TO_MULTIPLE_HOSTS
2018-04-20 05:08:46,753-04 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-6) [] Operation Failed: [Cannot ${action} ${type}. VM must be pinned to a single host.]
5 years, 12 months
OST Failure - Weekly update [14/04/2018-20/04/2018]
by Dafna Ron
Hi,
I wanted to give a short status on this week's failures and OST current
status.
We had one regression this week which was reported by Gal to the list and
was fix quickly.
The regression was caused by change:
https://gerrit.ovirt.org/#/c/90376/ - core: @Inject DAOs to QoS CRUD
commands
Tal debugged the issue and found that WELD doesn't allow injections of from
generic declared types and revered the change until the issue can be fixed (
https://gerrit.ovirt.org/#/c/90376/ - Revert "core: @Inject DAOs to QoS
CRUD commands").
We have an issue with CQ alerts (
https://ovirt-jira.atlassian.net/browse/OVIRT-1974) and we have been
monitoring CQ manually until the issue is resolved.
This is why I am unable to issue this week's statistics as they are based
on CQ reports on failures.
I am sure this would be fixed soon and I will be able to issue reports as
usual next week.
for now, please note that CQ looks good with no failures in the past few
hours.
Thank you,
Dafna
6 years
Wrong pep8 library on centos
by Petr Kotas
Hi,
Sending this to spread information.
I have encountered and issue with Centos 7.4.1708 (Core) when compiling the
oVirt engine.
The pep8 validation was not passing correctly.
It turned out, that the Centos has the old and bugged version present by
default.
The solution is to use the same version as used in oVirt CI.
Just add http://resources.ovirt.org/repos/ci-tools/el7/ to yum.repos.d and
it will start
passing again.
Best,
Petr
6 years
Broken repoclosure in today 4.2.3 RC2 compose
by Sandro Bonazzola
Hi,
today oVirt 4.2.3 RC2 release is blocked on repository closure error
detected by ovirt-engine-appliance build:
13:49:14 11:49:13,944 INFO program:Error: Package:
ovirt-engine-backend-4.2.3.2-1.el7.centos.noarch
(ovirt-4.2-pre)13:49:14 11:49:13,946 INFO program:Requires:
vdsm-jsonrpc-java >= 1.4.1213:49:14 11:49:13,947 INFO
program:Available: vdsm-jsonrpc-java-1.4.11-1.el7.noarch
(ovirt-4.2-centos-ovirt42)13:49:14 11:49:13,949 INFO
program:vdsm-jsonrpc-java = 1.4.11-1.el713:49:14 11:49:13,950 INFO
program:Available: vdsm-jsonrpc-java-1.4.11-1.el7.centos.noarch
(ovirt-4.2)13:49:14 11:49:13,951 INFO program:vdsm-jsonrpc-java =
1.4.11-1.el7.centos
Looks like vdsm-jsonrpc-java >= 1.4.12 has not been released yet.
Piotr please check its status and add it to release configuration file for
4.2.3 RC2. You can see an example in https://gerrit.ovirt.org/#/c/90436/
Thanks,
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://red.ht/sig>
<https://redhat.com/summit>
6 years
Fwd: [CentOS-devel] [SIG Process] Point-Release Freeze of SIG Content while CR is Active
by Sandro Bonazzola
FYI
---------- Forwarded message ----------
From: Brian Stinson <brian(a)bstinson.com>
Date: 2018-04-17 15:30 GMT+02:00
Subject: [CentOS-devel] [SIG Process] Point-Release Freeze of SIG Content
while CR is Active
To: centos-devel(a)centos.org
Hi Folks,
At the CBS meeting yesterday we discussed a proposal to freeze the Sign
and Push-to-mirror processes during the period between when CR is active
and a point release.
https://lists.centos.org/pipermail/centos-devel/2018-April/016610.html
You may recall that we did something similar for 7.1708
We need to Freeze because we make CR content available in CBS for
builds, and in CI for testing purposes. But, releasing content built
against CR to mirror.centos.org would have had some unintended
consequences (e.g. we don't want to require that end-users enable CR to
get content from the SIGs).
The Point-release Freeze does not affect content moving from the testing
tags in CBS to buildlogs.c.o, that will continue to show up as it is
built. Do note: since we do want to give testers and developers an
opportunity to build and test against an upcoming point-release before
it goes GA, content coming from buildlogs.centos.org may require
enabling the CR repo.
Any new requests for sign+push (adding new tags to mirror.c.o) during
Point-release Freeze will be held until the point release goes GA.
We approved this as part of the CR checklist during the meeting
yesterday, and will include another note about this in the CR release
announcement.
https://www.centos.org/minutes/2018/April/centos-devel.2018-04-16-14.00.html
If there are any questions, please let us know and discuss here on the
list.
Cheers!
--
Brian Stinson
_______________________________________________
CentOS-devel mailing list
CentOS-devel(a)centos.org
https://lists.centos.org/mailman/listinfo/centos-devel
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://red.ht/sig>
<https://redhat.com/summit>
6 years
[ OST Failure Report ] [ oVirt master ] [ 17.04.18 ] [ 002_bootstrap.add_qos ]
by Gal Ben Haim
Hi,
>From last night, the Change Queue fails on every run because of "add_qos"
test.
>From the engine log:
2018-04-16 10:31:51,813-04 ERROR
[org.ovirt.engine.core.bll.CommandsFactory] (default task-30) [] An
exception has occurred while trying to create a command object for
command 'AddCpuQos' with parameters
'QosParametersBase:{commandId='ccb4d6f4-ca86-4706-921c-f87439e0550f',
user='null', commandType='Unknown'}': WELD-001407: Cannot declare an
injection point with a type variable: [BackedAnnotatedField] @Inject
private org.ovirt.engine.core.bll.qos.QosCommandBase.qosDao
at org.ovirt.engine.core.bll.qos.QosCommandBase.qosDao(QosCommandBase.java:0)
2018-04-16 10:31:51,819-04 ERROR
[org.ovirt.engine.core.bll.CommandsFactory] (default task-30) []
Exception: org.jboss.weld.exceptions.DefinitionException: WELD-001407:
Cannot declare an injection point with a type variable:
[BackedAnnotatedField] @Inject private
org.ovirt.engine.core.bll.qos.QosCommandBase.qosDao
at org.ovirt.engine.core.bll.qos.QosCommandBase.qosDao(QosCommandBase.java:0)
StackTrace
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDefinitionErrors(Validator.java:295)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at org.jboss.weld.bootstrap.Validator.validateProducer(Validator.java:400)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at org.jboss.weld.injection.producer.InjectionTargetService.validateProducer(InjectionTargetService.java:36)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at org.jboss.weld.manager.InjectionTargetFactoryImpl.validate(InjectionTargetFactoryImpl.java:135)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:79)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:69)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at org.jboss.weld.manager.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:1140)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at org.jboss.weld.util.ForwardingBeanManager.createInjectionTarget(ForwardingBeanManager.java:201)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at org.ovirt.engine.core.di.Injector.injectMembers(Injector.java:29)
[vdsbroker.jar:]
at org.ovirt.engine.core.bll.CommandsFactory.createCommand(CommandsFactory.java:100)
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:433) [bll.jar:]
at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:387) [bll.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.8.0_161]
Link to all logs:
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6839/artifa...
--
*GAL bEN HAIM*
RHV DEVOPS
6 years
