- Devel - oVirt List Archives

vdsm on mere build fails on fc29
by Sandro Bonazzola 02 Oct '19

02 Oct '19

failure is: [2019-10-01T15:40:49.304Z] automation/common.sh: tests/profile: /usr/bin/python: bad interpreter: No such file or directory https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-on-merge… -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/>*Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours. <https://mojo.redhat.com/docs/DOC-1199578>*

2 1

CentOS 8 Mock is Available in STDCI
by Anton Marchukov 02 Oct '19

02 Oct '19

Hello All. We are happy to announce that CentOS 8 mock is now available for CI. As usual you will need to adjust your “automation” directory and use “el8” in “distros”. Then, “packages” and “repos” might need to be updated to accommodate CentOS changes. You can check the patch for “otopi” that was the first project onboarded there [1]. This effort is led by Galit (CCed), so you can reach her directly or use this list to reply with any issues. At this moment we are aware about unavailability on “pcc64le” and are working on it. As a next step we will also work on changing OST to run there, but it will not happen without oVirt packages build for “el8”. Thus you need to start transitioning your projects in CI now. [1] https://gerrit.ovirt.org/#/c/103620/ -- Anton Marchukov Associate Manager - RHV DevOps - Red Hat

2 1

planned gerrit restart
by Evgheni Dereveanchin 01 Oct '19

01 Oct '19

Hi everyone, I will be installing updates on gerrit.ovirt.org tonight. This means that both repos and code review will be unreachable for short periods of time. CI will also be paused temporarily to avoid false positives. I will announce you once maintenance is complete. -- Regards, Evgheni Dereveanchin

1 1

Recent ovirt-engine master patches are failing CI check-merged with UNSTABLE
by Andrej Krejcir 30 Sep '19

30 Sep '19

Hi, recently, patches merged to ovirt-engine are failing check-merged because of FindBugs. It seems the first patch that fails is: https://gerrit.ovirt.org/#/c/98623/ Here is the jenkins failure: https://jenkins.ovirt.org/job/ovirt-engine_master_check-merged-el7-x86_64/1… I haven't checked all the FindBugs failures, but they look like false positives. Roy, is it possible, that the patch changed some settings for FindBugs, and now it is more sensitive? Regards, Andrej

2 2

Enable power management on Host
by scott.fitzgerald＠oracle.com 30 Sep '19

30 Sep '19

Hi, I am currently trying to enable Power Management on a host. I have created a PowerManagementBuilder object, with an AgentBuilder. However, I am getting the error .Error: Fault reason is "Operation Failed". Fault detail is "[Cannot edit Host. Power Management is enabled for Host but no Agent type selected.]". HTTP response code is "400". HTTP response message is "Bad Request" sysService.hostsService().hostService(HostUtils.getHostObjectFromName(sysService, vdsmHostName).id()).update().host(host().powerManagement(powerManagementBuilder.build())).send(); Am I missing a step? Or could someone post the snippet of building an Agent and PowerManagement object so I can check against what I'm doing (below). TIA PowerManagementBuilder powerManagementBuilder = new PowerManagementBuilder(); AgentBuilder agentBuilder = new AgentBuilder(); agentBuilder.address(address); agentBuilder.concurrent(true); agentBuilder.host(host); agentBuilder.id("newAgent"); agentBuilder.name("newAgent"); agentBuilder.username("test"); agentBuilder.type("apc"); agentBuilder.port(22); agentBuilder.password("xxx"); sysService.hostsService().hostService(host.update().host(host().agents(agentBuilder.build())).send(); powerManagementBuilder.address(address); powerManagementBuilder.agents(agentBuilder.build()); powerManagementBuilder.automaticPmEnabled(true); powerManagementBuilder.enabled(true); powerManagementBuilder.password("xxx"); powerManagementBuilder.type("apc"); powerManagementBuilder.username("test"); sysService.hostsService().hostService(host).update().host(host().powerManagement(powerManagementBuilder.build())).send();

2 2

OST: Failure in next_run_unplug_cpu
by Milan Zamazal 30 Sep '19

30 Sep '19

Hi, I experienced the following OST failure on Friday: https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… It failed in next_run_unplug_cpu, due to the fact that the VM hadn't switched to UP status after reboot. I could run OST on the same patch successfully (besides a usual add_master_storage_domain failure) afterwards, so it looks like a random failure. I can see numerous guest agent timeouts after the VM start but other than that I couldn't find any error. The VM apparently has kept reporting POWERING_UP status, I can't see why it didn't switch to UP status eventually. Thanks, Milan

1 0

build-artifacts job stuck on s390x - cannot run OST
by Nir Soffer 29 Sep '19

29 Sep '19

Since Friday build-artifacts on s390x get stuck again, so we cannot run OST. This is not a new issue, we have issues on s390x every few weeks. I posted this patch to disable this job: https://gerrit.ovirt.org/c/97851 We can enable the job when we have a reliable build slave again. Here are some failed jobs: - http://jenkins.ovirt.org/job/standard-manual-runner/757/ - http://jenkins.ovirt.org/job/standard-manual-runner/758/ - http://jenkins.ovirt.org/job/standard-manual-runner/759/ - http://jenkins.ovirt.org/job/standard-manual-runner/762/ - http://jenkins.ovirt.org/job/standard-manual-runner/763/ - http://jenkins.ovirt.org/job/standard-manual-runner/764/ Nir

1 2

[oVirt] [CQ weekly status] [27-09-2019]
by Dusan Fodor 28 Sep '19

28 Sep '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.3*: GREEN (#3) Last failure was on 27-09 for v2v-conversion-host. Job was marked as failed because its on merge job (ghpush) tries to queue change in now non-existing 4.2 CQ. *CQ-Master:* RED (#1) Last failure was on 27-09 was for ovirt-engine on adding storage domain. This is a random failure described in thread "random failures for add_master_storage_domain", awaiting its fix. Another issue detected is in initialize_engine test, mail was sent to investigate it. Current running jobs for 4.3 [1] and master [2] can be found here: [1] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -4.3_change-queue-tester/ [2] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -master_change-queue-tester/ Have a nice week! Dusan ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3) _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt .org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt .org/message/YCNCKRK3G4EJXA3OCYAUS4VMKRDA67F4/

1 0

Error when removing unmanaged networks after Removal of Data Center
by scott.fitzgerald＠oracle.com 27 Sep '19

27 Sep '19

Hi, Test case is to remove a data center, validating the attached domain goes to an UNATTACHED state. This works, however, the code I am using to clean the system down after the test cannot remove the Default Management Network from the host as part of the cleanup of unmanaged networks. It returns a 400 error when running netService.unmanagedNetworkService(network.id()) .remove() .send(); For the Default Network, which is left on the host as a result of tearing down the Data Center, but the Host still being alive. If I tear down the host without removing the unmanaged network I get a successful test, but later use of the host results in errors relating to the same unmanaged network. In the engine log I see the following Exception: java.lang.IllegalStateException: There isn't unique management network for cluster <name> among networks (). Any help is much appreciated.

1 0

Re: [ovirt-users] oVirt and CentOS Stream
by Strahil 27 Sep '19

27 Sep '19

Should I understand that the most tested platform will be CentOS Stream 8 ? Will Fedora & CentOS 8 still viable option ? Best Regards, Strahil NikolovOn Sep 26, 2019 16:13, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote: > > Progress cannot be made without change. As technologists, we recognize this every day. Most of the time, these changes are iterative: progressive additions of features to projects like oVirt. Sometimes those changes are small, and sometimes not. And that’s, of course, just talking about our project. But one of the biggest strengths of our community’s software is that we are not alone, and because of that, changes to other projects have ripple effects that can affect our own, even in positive ways. > > > This week, our collaborators in the CentOS Project have announced a change in the way their software is released moving forward. > > Beyond this week release of CentOS Linux 8, the CentOS team has announced CentOS Stream, a rolling release distribution that will be the "midstream" between Fedora and Red Hat Enterprise Linux. > > > To be clear, Fedora will remain as the first upstream of RHEL. But when RHEL branches off, CentOS will be upstream for ongoing work on those RHEL versions. This change gives public visibility into ongoing work on released RHEL, and a place for developers and community projects like ours to collaborate at that level. > > > CentOS has been heading in the direction of Stream for quite some time. CentOS SIGs — the special interest groups for virtualization, storage, config management, and so on — have given our project a way to provide input into the CentOS platform. Now, though, we can actually provide direct improvements or fixes to CentOS Stream platform that will be beneficial to our project. Long-term, those project-specific changes can find their way into the next release of RHEL, providing smoother transitions for those users of our downstream projects. > > > We expect the positive effects to extend beyond our own project’s ecosystem. Through CentOS Stream, developers will have early access to new features and content that are being built into the upcoming RHEL version. This will help to allow next-generation applications to have compatibility with future versions of RHEL. > > > The benefits of these changes are clear for ecosystem developers working on projects such as ours, writing hardware drivers, or extending protocols for RHEL. As we push the innovations that start in Fedora through the new CentOS Stream, the community will have a clear vision of the future of Red Hat Enterprise Linux. > > > For users of oVirt, we expect CentOS Stream to be the preferred upstream platform on which oVirt should be run, especially with the capability for our users to now contribute changes to our software and the community-built platform on which oVirt runs. > > > > -- > > Sandro Bonazzola > > MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV > > Red Hat EMEA > > sbonazzo(a)redhat.com > > Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.

3 3