September 2019 - Devel - oVirt List Archives

[VDSM] Started getting virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired
by Edward Haas 11 Jan '24

11 Jan '24

Hi, I have a VM which acts as an oVirt host with VDSM installed. I use it for testing without connecting it to Engine. Recently VDSM fails to come up and I see this error: Sep 26 17:58:18 localhost libvirtd: 2018-09-26 14:58:18.978+0000: 12176: error : virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired Any hint on how to generate or fetch a new certificate without the help of Engine? Thanks, Edy.

3 5

Error: Adding new Host to ovirt-engine
by Ahmad Khiet 14 Aug '23

14 Aug '23

Hi, Can't add new host to ovirt engine, because the following error: 2019-06-12 12:23:09,664 p=4134 u=engine | TASK [ovirt-host-deploy-facts : Set facts] ************************************* 2019-06-12 12:23:09,684 p=4134 u=engine | ok: [10.35.1.17] => { "ansible_facts": { "ansible_python_interpreter": "/usr/bin/python2", "host_deploy_vdsm_version": "4.40.0" }, "changed": false } 2019-06-12 12:23:09,697 p=4134 u=engine | TASK [ovirt-provider-ovn-driver : Install ovs] ********************************* 2019-06-12 12:23:09,726 p=4134 u=engine | fatal: [10.35.1.17]: FAILED! => {} MSG: The conditional check 'cluster_switch == "ovs" or (ovn_central is defined and ovn_central | ipaddr and ovn_engine_cluster_version is version_compare('4.2', '>='))' failed. The error was: The ipaddr filter requires python's netaddr be installed on the ansible controller The error appears to be in '/home/engine/apps/engine/share/ovirt-engine/playbooks/roles/ovirt-provider-ovn-driver/tasks/configure.yml': line 3, column 5, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: - block: - name: Install ovs ^ here 2019-06-12 12:23:09,728 p=4134 u=engine | PLAY RECAP ********************************************************************* 2019-06-12 12:23:09,728 p=4134 u=engine | 10.35.1.17 : ok=3 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 whats missing!? Thanks -- Ahmad Khiet Red Hat <https://www.redhat.com/> akhiet(a)redhat.com M: +972-54-6225629 <https://red.ht/sig>

7 10

Error Java SDK Issue??
by Geschwentner, Patrick 02 Apr '21

02 Apr '21

Dear Ladies and Gentlemen! I am currently working with the java-sdk and I encountered a problem. If I would like to retrieve the disk details, I get the following error: Disk currDisk = ovirtConnection.followLink(diskAttachment.disk()); The Error is occurring in this line: [cid:image001.png@01D44537.AF127FD0] The getResponst looks quiet ok. (I inspected: [cid:image002.png@01D44537.AF127FD0] and it looks ok). Error: wrong number of arguments The code is quiet similar to what you published on github (https://github.com/oVirt/ovirt-engine-sdk-java/blob/master/sdk/src/test/jav… ). Can you confirm the defect? Best regards Patrick

6 11

Dropping local crypto settings throughout oVirt in favour of crypto policies
by Marcin Sobczyk 07 Nov '19

07 Nov '19

Hi, given that crypto policies appeared in RHEL8 I think it's a good time to discuss using them throughout oVirt. I prepared a document, that describes the current state of crypto settings in VDSM along with the benefits and potential issues that come with moving to crypto policies. If you have a moment, please go through the doc - any input and comments are welcome. https://docs.google.com/document/d/1K19jDOITEQenPDbbSft2ChgGrL_DgpcbQon_bWL… Regards, Marcin Sobczyk

2 2

IMPORTANT: OST is now gated.
by Ehud Yonasi 29 Oct '19

29 Oct '19

Hey everyone, OST project is now enabled for patch gating. What is the meaning of this? 1. The gating process will start when Code-Review +2, CI +1 and Verified +1 labels are turned on. 2. Every patch before merging will have to pass the following suites: - *oVirt-master* *oVirt-4.3* basic_suite basic_suite upgrade-from-release upgrade-from-release upgrade-from-prevrelease 3. Patches should no longer be manually merged in OST, they will be merged automatically when passing the gate. *NOTE: *Maintainers are still able to merge manually, but it is not recommended if the gate is not passing. *NOTE:* For additional information regarding the gating I've sent FAQ mail - 'Patch Gating summary + FAQ' Regards, Ehud.

4 4

Ovirt SDK: Problems retrieving the storage domain, status null when not in active or unattached state
by donagh.moran＠oracle.com 11 Oct '19

11 Oct '19

Hi as the subject suggests I'm having problems reading the state of the Storage Domain when not in one of two states active or unattached. I am developing in Java an reading the state with the piece of code below StorageDomain sd = sysService.storageDomainsService().list() .search(storageDomainName) .send() .storageDomains() .get(0); sd.status(); Issue when deactivating In the UI it goes from active too inactive. When I recursively get the storage domain and check its status via the SDK the status never gets set to inactive, instead it goes from inactive to null and stays o a null state. Issue when activating In the UI it goes from unattached, locked then active. When I recursively get the storage domain and check its status via the SDK it goes from unattached null then active. As far as I can tell the only two states detected are unattached and active out of the ENUM of possible states listed below, of which non are null. I presume as I can check for two of the eight possible states, that means I am correct in my approach. ACTIVATING("activating"), ACTIVE("active"), DETACHING("detaching"), INACTIVE("inactive"), LOCKED("locked"), MAINTENANCE("maintenance"), MIXED("mixed"), PREPARING_FOR_MAINTENANCE("preparing_for_maintenance"), UNATTACHED("unattached"), UNKNOWN("unknown"), Any help would be much appreciated, on whether this is a potential known or unknown bug or whether I doing something wrong in my approach to retrieving the state of the domain. Regards Donagh

2 2

Please remove 4.2 from your stdci.yaml files
by Dafna Ron 09 Oct '19

09 Oct '19

Hi, We have several unstable jobs which are caused because 4.2 is no longer available for CQ. Please remove 4.2 from your stdci.yaml files to avoid getting unstable jobs. Thanks, Dafna

2 2

ovirt-engine fails CQ due to broken engine-setup
by Dusan Fodor 03 Oct '19

03 Oct '19

Hello all, initialize_engine test fails in CQ due to utf8/unicode type mismatch in engine-setup/ answer file: [ ERROR ] Failed to execute stage 'Clean up': must be unicode, not str The suspected change: https://gerrit.ovirt.org/#/c/102934/ Failed job example: https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chang… <https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_chang…> Can you please this? Thanks

5 5

planned gerrit restart
by Evgheni Dereveanchin 30 Sep '19

30 Sep '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

ovirt-engine on master compiles and runs on Java-11
by Roy Golan 27 Sep '19

27 Sep '19

Hi all, ovirt-engine project reached a nice milestone, compiling and running on Java-11 📣 The move itself needed care to see nothing breaks and with the help of OST it remaind like unbroken, but the move was mostly painless and didn't require changes to real business logic code. It was mainly to deal with 2 things, working with modules and lack of support from GWT. Modular JDK (project jigsaw) landed in java-9 is more relevant to the delivery of the sofware rather to the development of it. Specifically now you can ship your software only with a subset of the jdk, or produce your jar as a module so it can expose or hide internal with real enforcment(even no reflection). The relevant part to the change here is that java doesn't provide EE code in the jdk, specifically java.xml, java.annotation, javax.activation [1] GWT and specifically the gwt compiler doesn't recognize java syntax beyond 8, and efforts of the community to support don't look promising. Luckily since it is strictly compile-time only concern the invocation of the gwt compiler, which is invoked by maven, is instructed to use java-8 javac. This means the frontend artifacts are remain uneffected by this change. Morning comes, I want to rebase and compile the project! This should not be huge change, and is document here [2]: - install java-11-openjdk-devel - make java-11 binaries available on your path *before java-8 *(use your favorite method I use alternatives) - install maven >= 3.5.0 Please report any problem here and also if the README [2] is not helping enough please help improve it! P.S - Obviously it is strongly encouraged to get familiar with what java 9, 10, and 11 brought in and start make use of it. If you think you have code you want to contribute to master, but is going to be backported to 4.3 bare in mind the difference in java version. Thanks, Roy [1] covered in the git log https://gerrit.ovirt.org/#/c/98623/ [2] https://github.com/oVirt/ovirt-engine/blob/master/README.adoc#note-on-java-…

1 0

Setting reason for VM shutdown
by scott.fitzgerald＠oracle.com 26 Sep '19

26 Sep '19

Hi all, I have a test case as follows: Enable "require reason for vm maintenance" on Cluster Shutdown vm Ensure reason is saved A similar case for hosts is achieved by the following hostsService .hostService(host.id()) .deactivate() .reason(reason) .send(); But the shutdown option for vms does not have a reason option. How can I set the reason for shutdown of a VM through the SDK? TIA

3 3

Using SDK to find VM Network Role
by Jamie Holohan 26 Sep '19

26 Sep '19

I am trying to verify whether a Networks VM Network checkbox is checked using the SDK, but I cannot see any methods or variable with a similar name. Is it possible to find out if a network has a VM Network Role using the SDK?

2 1

Re: [CQ]: 103548,1 (vdsm) failed "ovirt-4.3" system tests
by Nir Soffer 26 Sep '19

26 Sep '19

On Thu, Sep 26, 2019 at 3:55 PM oVirt Jenkins <jenkins(a)ovirt.org> wrote: > Change 103548,1 (vdsm) is probably the reason behind recent system test > failures in the "ovirt-4.3" change queue and needs to be fixed. > > This change had been removed from the testing queue. Artifacts build from > this > change will not be released until it is fixed. > This is a bug in the change queue, because For further details about the change see: > https://gerrit.ovirt.org/#/c/103548/1 this is a travis configuration change, and it cannot break system tests :-) Do we have stats of such failures in the past? For failed test results see: > http://jenkins.ovirt.org/job/ovirt-4.3_change-queue-tester/2188/ Maybe we can add a simple file based condition to tell if a patch need to run system tests? For example in vdsm we have this structure: lib/ static/ tests/ automation/ .travis.ymal ... Changes in tests/ and automation/ cannot break vdsm during runtime, so there is no need to run system tests for patches modifying these directories. Here are changes stats per directory since 4.2: $ git shortlog -sn --since v4.20.0 ./tests ./automation | awk '{sum+=$1} END {print sum}' 4579 $ git shortlog -sn --since v4.20.0 ./lib ./static | awk '{sum+=$1} END {print sum}' 4413 So 50% of the changes cannot break the system and do not require system tests. SLOC Directory SLOC-by-Language (Sorted) 65205 lib python=64977,sh=228 62415 tests python=62317,sh=98 3432 vdsm_hooks python=3432 803 contrib python=740,sh=63 468 automation sh=454,python=14 313 static python=210,sh=103 289 init sh=162,python=127 112 build-aux sh=72,python=40 64 top_dir sh=64 30 doc python=30 30 helpers python=30 1 vdsm_log sh=1 0 docker (none) 0 m4 (none) We can see that the tests are about 50% of the code. This is pretty good for legacy project, but if we look in a more modern project like ovirt-imageio: common: SLOC Directory SLOC-by-Language (Sorted) 3641 test python=3641 2365 ovirt_imageio_common python=2201,ansic=164 103 top_dir python=103 daemon: SLOC Directory SLOC-by-Language (Sorted) 1588 test python=1588 792 ovirt_imageio_daemon python=792 18 top_dir python=18 0 data (none) We see that test code ratio is close to 2/1. So adding a filter per project that can tell if a patch needs system tests very important, and can speed our workflow by fact of 2-3. Adding infra-support to file a bug, we need to work on this. Nir

2 1

oVirt and CentOS Stream
by Sandro Bonazzola 26 Sep '19

26 Sep '19

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 <https://lists.centos.org/pipermail/centos-announce/2019-September/023449.ht…> 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 <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.*

1 0

OST fails on 004_basic_sanity.verify_glance_import
by Yedidyah Bar David 26 Sep '19

26 Sep '19

Hi all, [1], which I ran for verifying [2], fails for me at 004_basic_sanity.verify_glance_import . I can see several different cases of failure there reported to devel@, last one 1.5 months ago. Is this a (new) known issue? [1] https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… [2] https://gerrit.ovirt.org/97698 Thanks and best regards, -- Didi

4 4

vdsm check patch failed on loopback.py#test_with_device
by Eyal Shenitzky 26 Sep '19

26 Sep '19

Hi, Jenkins check-patch job is failing on: =================================== FAILURES =================================== 15:19:02 ____________________________ test_with_device[4096] ____________________________ 15:19:02 15:19:02 tmpdir = local('/var/tmp/vdsm/test_with_device_4096_0'), sector_size = 4096 15:19:02 15:19:02 @requires_root 15:19:02 @pytest.mark.parametrize("sector_size", [ 15:19:02 None, 15:19:02 pytest.param(sc.BLOCK_SIZE_512, marks=requires_loopback_sector_size), 15:19:02 pytest.param(sc.BLOCK_SIZE_4K, marks=[ 15:19:02 requires_loopback_sector_size, 15:19:02 pytest.mark.xfail( 15:19:02 testing.on_ovirt_ci() and testing.on_fedora("29"), 15:19:02 reason="fails randomly to create loop device with 4k sector " 15:19:02 "size, only in ovirt CI - needs investigation") 15:19:02 ]), 15:19:02 ]) 15:19:02 def test_with_device(tmpdir, sector_size): 15:19:02 filename = str(tmpdir.join("file")) 15:19:02 prepare_backing_file(filename) 15:19:02 > with loopback.Device(filename, sector_size=sector_size) as device: 15:19:02 15:19:02 storage/loopback_test.py:57: 15:19:02 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 15:19:02 storage/loopback.py:99: in __enter__ 15:19:02 self.attach() 15:19:02 storage/loopback.py:66: in attach 15:19:02 out = commands.run(cmd) 15:19:02 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 15:19:02 I noticed that was a recent fix for that test - https://gerrit.ovirt.org/#/c/100928/ Link to the failing job - https://jenkins.ovirt.org/job/vdsm_standard-check-patch/12021/consoleFull Nir, can you have a look? -- Regards, Eyal Shenitzky

2 1

ovirt-engine has been tagged (ovirt-engine-4.2.8.9)
by Tal Nisan 26 Sep '19

26 Sep '19

1 0