April 2018 - Devel - oVirt List Archives

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

Removing validateQemuReadable check
by Andrew DeMaria 23 Apr '18

23 Apr '18

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

1 0

Disabling STDCI V1 OST jobs
by Daniel Belenky 22 Apr '18

22 Apr '18

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

1 0

OST failure: 002_bootstrap.configure_high_perf_vm2
by Milan Zamazal 21 Apr '18

21 Apr '18

Hi, I experienced the following OST failure on my OST patch: http://jenkins.ovirt.org/job/ovirt-system-tests_master_check-patch-el7-x86_… 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.]

2 2

OST Failure - Weekly update [14/04/2018-20/04/2018]
by Dafna Ron 20 Apr '18

20 Apr '18

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

1 0

Wrong pep8 library on centos
by Petr Kotas 20 Apr '18

20 Apr '18

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

2 1

Broken repoclosure in today 4.2.3 RC2 compose
by Sandro Bonazzola 18 Apr '18

18 Apr '18

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>

2 1

Fwd: [CentOS-devel] [SIG Process] Point-Release Freeze of SIG Content while CR is Active
by Sandro Bonazzola 18 Apr '18

18 Apr '18

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>

1 0

[ OST Failure Report ] [ oVirt master ] [ 17.04.18 ] [ 002_bootstrap.add_qos ]
by Gal Ben Haim 17 Apr '18

17 Apr '18

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/artifact… -- *GAL bEN HAIM* RHV DEVOPS

2 2