- Devel - oVirt List Archives

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

[OST][HC] HE fails to deploy
by Sahina Bose 16 Apr '18

16 Apr '18

HE fails to deploy at waiting for host to be up in the local HE VM. The setup logs does not indicate why it failed - atleast I couldn't find anything ---------- Forwarded message ---------- From: <jenkins(a)jenkins.phx.ovirt.org> Date: Mon, Apr 2, 2018 at 7:50 PM Subject: [oVirt Jenkins] ovirt-system-tests_hc-basic-suite-master - Build # 276 - Still Failing! To: infra(a)ovirt.org, sabose(a)redhat.com Project: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic- suite-master/ Build: http://jenkins.ovirt.org/job/ovirt-system-tests_hc-basic- suite-master/276/ Build Number: 276 Build Status: Still Failing Triggered By: Started by timer ------------------------------------- Changes Since Last Success: ------------------------------------- Changes for Build #265 [Gal Ben Haim] Check if the prefix exists before printing its size [Sandro Bonazzola] ovirt-engine: add jobs for 4.1.10 async Changes for Build #266 [Gal Ben Haim] Check if the prefix exists before printing its size Changes for Build #267 [Gal Ben Haim] Check if the prefix exists before printing its size [Daniel Belenky] ppc repos: Use qemu EV release instead of test [Daniel Belenky] global_setup: Add generic package remove function [Daniel Belenky] Fix package verification in verify_packages Changes for Build #268 [Gal Ben Haim] Check if the prefix exists before printing its size Changes for Build #269 [Gal Ben Haim] Check if the prefix exists before printing its size Changes for Build #270 [Gal Ben Haim] Check if the prefix exists before printing its size Changes for Build #271 [Gal Ben Haim] Check if the prefix exists before printing its size Changes for Build #272 [Gal Ben Haim] Check if the prefix exists before printing its size Changes for Build #273 [Eitan Raviv] network: macpool: test disallowing dups while dups exist [Daniel Belenky] docker cleanup:Fix edge case for unamed containers [Daniel Belenky] nested_config: Count nesting level of options [Daniel Belenky] Introduce conditional execution in STDCI DSL [Daniel Belenky] Add OST STDCI V2 jobs Changes for Build #274 [Gal Ben Haim] he-iscsi-master: Temporarily exclude in check-patch Changes for Build #275 [Gal Ben Haim] he-iscsi-master: Temporarily exclude in check-patch Changes for Build #276 [Barak Korren] Force STDCI V2 job to use physical host [Daniel Belenky] Build container on changes to docker_cleanup ----------------- Failed Tests: ----------------- No tests ran.

3 7

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

13 Apr '18

On Fri, Apr 13, 2018 at 3:49 PM, Dafna Ron <dron(a)redhat.com> wrote: > Hello, > > I would like to update on this week's failures and OST current status. > > We had some issues from previous week. once is still sporadically failing > but since there were a few patches merged and another one in the processes > I decided we can close this sprint with no backlog. > > this week's failures were one regression, sporadic failures and one > packaging issue. > > We are still seeing sporadic failures on migration tests but Gal has a fix > which would probably be merged soon. https://gerrit.ovirt.org/#/c/90166/ > - master,4.2: Wait for migration to end > > we have found and reported a regression change: > https://gerrit.ovirt.org/#/c/89581/ - Subnet name should be an optional > field > This was fixed quickly by: https://gerrit.ovirt.org/#/c/89980/ - Fix > mistaken mapping for retrieving subnet name from row > > We moved to Ansible 2.5 but the packages were not updated in the repos. > this was fixed by this change: https://gerrit.ovirt.org/#/c/90015/ - 4.2: > Take ansible from epel > > > > *Below you can see the chart for this week's resolved issues but cause of > failure:**Code* = regression of working components/functionalities > *Infra* = infrastructure/OST Infrastructure/Lago related issues/Power > outages > *OST* *Tests *- package related issues, failed build artifacts > > > > > > > > > > > *Below is a chart of resolved failures based on ovirt version:* > > > > *Below is a chart showing failures by suite type: * > > > *Below you can see the issues opened this week vs the backlog issues from > previous week: * > > > Thanks, > Dafna > > > > > > > >

1 0