- Devel - oVirt List Archives

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 28 Sep '19

28 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

Patch Gating summary + FAQ
by Ehud Yonasi 27 Sep '19

27 Sep '19

Hey everyone, Following the presentation we did last week [1] <https://bluejeans.com/s/zAjyX/>, I wanted to summarize the new patch gating workflow that will be pushed to oVirt soon and will impact all the developers. Summary: The purpose of the new workflow is to verify patches earlier ( shift left ) before they are merged and provide much faster feedback for developers if their patch fails OST. 1. Feedback from OST will now be posted directly to Gerrit instead of requiring human intervention from the infra team to notify developers We expect developers to check why their patch is not passing the gate (OST), debug it, find the root cause and fix it before merging the patch. 1. Any concerns regarding the stability of OST should be communicated and addressed ASAP. The status today is that if OST fails post-merge gating packages are not pushed to tested and QE doesn’t get to test them. The change with pre-merge gating is that patches won’t be merged if OST fails, so if there are any fragile or flaky tests they should be examined by their maintainers and fixed, skipped or removed by the maintainers. 1. FYI, we are not removing the Merge button at this point, so maintainers will still be able to merge patches that they believe 100% is not breaking the build and failing OST tests. Please note that merging patches that break OST will cause it to start failing for all other patches, we urge you to avoid trying to bypass it if at all possible. In the following section, I will explain more on Patch Gating, how to onboard it, etc. FAQ on oVirt’s Gating System and how to onboard your project on it: Q. What is Patch Gating? A. It is triggered pre-merge on patches and running OST as the gate system tests, unlike today where we have post-merge OST that runs the patches after the projects are merged. This means developers get early feedback on their patches if it is passing OST. Q. What causes the gating process to start? A. Once a patch is verified, passed CI and has Code-Review +2 labels, the gating process will be started. You will receive a message in the patch Q. How does it report results to my patches? A. A comment will be posted in your patch with the job URL failure. Q. How will my patch get merged? A. If the patch has passed the gating (OST), Zuul (The new CI system for patch gating) will merge the patch automatically. Q. How do I onboard my project? A. 1. Open a JIRA ticket or mail to infra-support(a)ovirt.org 2. Creating a file named 'zuul.yaml' under your project root OR `zuul.d/zuul.yaml` and fill with the following content: - project: templates: - ost-gated-project Q. My projects run on STDCI V1, is that ok? A. No, the patch gating logic runs on STDCI V2 only! meaning that you will have to shift your project to V2. If you need help regarding the transition to V2 you can open a JIRA[2] <https://ovirt-jira.atlassian.net>ticket or mail to infra-support(a)ovirt.org and visit the docs [3] <https://ovirt-infra-docs.readthedocs.io/en/latest/>. Q. What if I want to merge the patch regardless of OST results? A. If you are a maintainer of the project, you can still merge it. we are not removing the merge button option. But, merging when failing OST can break your project so merging on failure is unadvertised. Q. What if my patch failing because of dependency on different project patch? A. Patch Gating (Zuul) has a mechanism for cross-project dependency! All you need to do is to add to the commit message the patch URL you are dependent on: Depends-On: https://gerrit.ovirt.org/patch_number And they will be tested together. Note: you can have multiple dependencies. Q. How do I debug OST? A. There are various ways of looking in the logs and output for the errors: 1. Blue Ocean view, <https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_gat…> you can see the jobs that were run inside the gate and find the suites which failed. 2. ci_build_summary view, An internal tool to view the threads and redirect to the specific logs/artifacts. 3. Test results analyzer, available if the tests were run. you can view the failed tests and their output and OST maintainers and your team leads should be able to assist. 4. For further learning on how to debug OST please visit the OST FAQ <https://drive.google.com/open?id=1Sohq7bdgZS341gs5-lvB9lyS0GXawqaIvuUziOWwo…> . Q. Will the current infrastructure be able to support all the patches? A. The CI team has made tremendous work in utilizing the infrastructure. The OST gating will run inside OpenShift pods unlike before as bare metals and we can gain from that right now approximately 50 pods in parallel to run simultaneously and we will review adding more if the need arises. Q. When I have multiple patches, in which order will they be tested by the gating system? A. The patches will be tested as the flow they will be merged. The gating system knows how to simulate patches post-merge. Q. What do I do if I think OST failed because of an infra issue and not my patch? A. You can contact the CI team by sending mail to infra-support(a)ovirt.org and explain your concerns + sending the patch URL. Q. Will check-merged scripts be used by the gating system? A. No, they will be used in the current workflow with OST post-merge gating system called Change-Queue. Q. Can I add my own tests to the gating system? A. The gating system is running OST tests, so if it’s a test that should be included in the OST, then yes. Q. What will happen to the old change-queue system now that we have gating? A. At this time, the change-queue system will stay and gate post-merge jobs until all of oVirt projects will onboard to patch gating. We might consider using the change-queue for further coverage of tests in the future. Q. How can I re-trigger a failed patch to the gate again? A. There are 2 options to retrigger: - If the case is to fix your patch, just uploaded a new patchset and turn the Code-Review, Verified and CI labels again. - If you want to re-trigger the same patchset again just write a comment in Gerrit: ‘ci emulate-gate please’ Q. I usually write a series of related patches that should be merged together, can the Gating system test all of them in a single test? A. No, they will be tested in parallel as the number of patches in the series. This is why we’ve increased our capacity to run OST for this case. Architectural design document [4] <https://drive.google.com/open?id=1qV_iNJL6jHARlti7zpnRZRfQM_Q9Z-w8ONvcKEmaA…> would provide you the understanding of the patch gating process with the new services we will be using. [1]: https://bluejeans.com/s/zAjyX/ [2]: https://ovirt-jira.atlassian.net [3]: https://ovirt-infra-docs.readthedocs.io/en/latest/ [4] https://drive.google.com/open?id=1qV_iNJL6jHARlti7zpnRZRfQM_Q9Z-w8ONvcKEmaA…

5 6