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 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

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

Outage Notification: Jenkins and Resources Are Not Accessible
by Anton Marchukov 26 Sep '19

26 Sep '19

Hello All. Please note that oVirt services hosted at PHX datacenter are not accessible. Main services running there are: jenkins.ovirt.org resources.ovirt.org This looks to be network related and we are working with the relevant teams to resolve it. Anton. -- Anton Marchukov Associate Manager - RHV DevOps - Red Hat

1 1

PROBLEM: Unable to retrieve value for MTU when default is used
by james.holohan＠oracle.com 26 Sep '19

26 Sep '19

I'm trying to automate a test which checks that the default values are being set correctly when adding a network to a host. When I create a network without specifying a value for the MTU, I can see from the web UI that the default value (1500) is being used. When I try to retrieve this MTU value from the SDK to ensure it is set correctly, the value returned is '0'. The same issue is not occurring if I explicitly set the MTU value when creating the network. When the MTU value is assigned, instead of using the default value, it is possible to retrieve it from the SDK correctly. Is there any way I can retrieve the value for MTU from the SDK when the default is used?

3 4

[ACTION REQUIRED] unicode patches merged, update otopi
by Yedidyah Bar David 26 Sep '19

26 Sep '19

Hi all, I now merged my pending patches to make otopi use unicode strings for "everything" (well, partially, for now) instead of "str" in python2. There were two stacks of patches - one for the engine and one for otopi. So if you git pull from the engine and it breaks, try to update otopi and see if it helps. If not, ping me :-) Best regards, -- Didi

1 1

planned Jenkins restart
by Evgheni Dereveanchin 26 Sep '19

26 Sep '19

Hi everyone, I'll be performing a planned Jenkins restart within the next hour. No new jobs will be scheduled during this maintenance period. I will inform you once it is back online. -- Regards, Evgheni Dereveanchin

1 1

CI is not triggered for pushed gerrit updates
by Amit Bawer 25 Sep '19

25 Sep '19

CI has stopped from being triggered for pushed gerrit updates. Example at: https://gerrit.ovirt.org/#/c/103320/ last PS did not trigger CI tests. Please advise.

3 3

PROBLEM: Issue has been detected with gerrit trigger.
by Ehud Yonasi 25 Sep '19

25 Sep '19

Hey everyone, A problem was identified that causes the CI not working with gerrit patches. We are working on fixing the automatic triggering and bringing it online asap. We are sorry for the inconvenience at the moment. If you want to run the CI for your patch atm you can use the manual gerrit trigger job: https://jenkins.ovirt.org/gerrit_manual_trigger/ Regards, Ehud.

1 2

vdsm has been tagged (v4.30.33)
by Milan Zamazal 24 Sep '19

24 Sep '19

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.5.6)
by Tal Nisan 24 Sep '19

24 Sep '19

1 0

unicode sandwich in otopi/engine-setup
by Yedidyah Bar David 24 Sep '19

24 Sep '19

Hi all, This is in a sense a continuation of the thread "Why filetransaction needs to encode the content to utf-8?", but I decided that a new thread is better. I started to systematically convert the code to use a unicode sandwich. I admit it was harder than I expected, and made me think somewhat differently about the move to python3, and about how reasonable (or not) it is to develop in the common subset of python2 and python3 vs ditching python2 and moving fully to python3. It seems like at least parts of our (integration team) code will still have to run in python2 also in oVirt 4.4, so I guess we'll not have much choice :-) Current patches are only for otopi and engine-setup, and are by no means thorough - I didn't check each and every open() call and similar ones. But it's enough for getting engine-setup finish successfully on both python2 and python3 (EL7 and Fedora 29), with some utf-8 inserted in relevant places of the input (for the plugins already handled). I didn't bother trying non-utf-8 encodings. Perhaps I should, but it's not completely clear to me what's the best approach [2]. Currently, you must have both otopi and engine updated to get things working. If there is demand, I might spend some time splitting/rebasing/etc to make it possible to update just one of them and only later the other, but not sure it's worth it. I don't mind splitting/squashing if it makes reviews simpler, but I think the patches are ok as-is. These are the bottom patches of each stack: otopi: https://gerrit.ovirt.org/102085 engine-setup: https://gerrit.ovirt.org/102934 [1] http://python-future.org/unicode_literals.html [2] https://stackoverflow.com/questions/4012571/python-which-encoding-is-used-f… Thanks and best regards, -- Didi

2 5

ovirt-engine has been tagged (ovirt-engine-4.3.6.6)
by Tal Nisan 23 Sep '19

23 Sep '19

1 0

Re: Certificate checking on TLS migrations to an IP address
by Milan Zamazal 23 Sep '19

23 Sep '19

Daniel P. Berrangé <berrange(a)redhat.com> writes: > On Wed, Sep 04, 2019 at 03:38:25PM +0200, Milan Zamazal wrote: >> Hi, I'm trying to add TLS migrations to oVirt, but I've hit a problem >> with certificate checking. > >> >> oVirt uses the destination host IP address, rather than the host name, >> in the migration URI passed to virDomainMigrateToURI3. One reason for >> doing that is that a separate migration network may be used for >> migrations, while the host name resolves to the management network >> interface. >> >> But it causes a problem with certificate checking. The destination IP >> address is checked against the name, which is a host name, given in the >> destination certificate. That means there is mismatch and the migration >> fails. I don't think it'd be a very good idea to avoid the problem by >> putting IP addresses into server certificates. > > In fact that is *exactly* what you should be doing. > > Traditionally certificates were created with the 'common name' field > holding the fully qualified DNS based hostname for the server. > > This was long known to be a problem because it is very common for > servers to have multiple DNS names, or for clients to use the > unqualified hostname, or use the IP address(es). The problem with putting IP addresses into certificates is that the certificate must be updated each time an IP address changes, is added or is removed. Doing this in oVirt would be complicated and error-prone. While host names are stable, host networks and the related IP addresses may change. > Thus, the "Subject alt name" extension was created. This allows > certificates to be created containing multiple hostnames and > multiple IP addresses. The certificate will be validated correctly > if any one of those data items matches. When 'subject alt name' is > present in a certificate, the 'common name' field should be completely > ignored by compliant TLS clients, so you are free to put whatever > you want in the common name - hostname or IP address or blah... We can switch to using Subject Alt Name and we have a patch for that now based on your advice, but it doesn't solve the problem with tracking IP address changes and updating the corresponding certificates whenever a change occurs. > If you look at our docs, we updated them to illustrate how to > issue certs containing hostnames + IP addresses: > > https://libvirt.org/remote.html#Remote_TLS_server_certificates > >> >> Is there any way to make TLS migrations working under these >> circumstances? For instance, SPICE remote-viewer allows the client to >> specify the certificate subject to expect on the host when connecting to >> it using an IP address. Can (or could) libvirt do something similar? Would it be possible? We have host names in the certificates under our control and we know which host name to expect in the certificate regardless the IP address used for the given connection. Checking the certificate against a given host name would solve the problem easily and robustly for us. >> Or is there any other mechanism to handle this problem? Thanks, Milan

2 4

Not getting desired output for ovirt backup script.
by smidhunraj＠gmail.com 23 Sep '19

23 Sep '19

I am trying to run the code of https://github.com/wefixit-AT/oVirtBackup/blob/master/backup.py I am getting output as ovirtsdk.infrastructure.brokers.VMSnapshot object at 0x7fe9e59371d0 for the snippet print vm.snapshots.list(config.get_snapshot_description()) Is this the expected output. When i run the whole code .. The log i get is ... 2019-09-23 12:34:47,263: Start backup for: test2-sep20__vm25-183 2019-09-23 12:34:48,978: Snapshot creation started ... 2019-09-23 12:34:48,978: Snapshot created 2019-09-23 12:34:59,926: !!! No snapshot found !!! 2019-09-23 12:34:59,926: All backups done 2019-09-23 12:34:59,926: Backup failured for: 2019-09-23 12:34:59,927: test2-sep20__vm25-183 2019-09-23 12:34:59,927: Some errors occured during the backup, please check the log file Could you guys please help me.

1 0

vdsm has been tagged (v4.30.32)
by Milan Zamazal 23 Sep '19

23 Sep '19

1 0

master CQ: random failures for add_master_storage_domain
by Dusan Fodor 20 Sep '19

20 Sep '19

Hello all, lately i witnessed multiple failures for add_master_storage_domain test, which were not related to changes themselves, nor any infra issue. One example can be found here [1]. After investigation with huge help of Milan, issue is that Host falls from up state to whatever-but-not-up suddenly. 1. add_storage_domain picks a random host that is in up state 2. meantime engine starts fence action for it, so probably something gone bad with the host; the fence action fails with: *[org.ovirt.engine.core.bll.pm.FenceProxyLocator] (EE-ManagedThreadFactory-engineScheduled-Thread-38) [6692895f] Can not run fence action on host 'lago-basic-suite-master-host-0', no suitable proxy host was found.* 3. test fails on not being able to attach the domain to non-up host: *[org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-1) [] Operation Failed: [Cannot add storage server connection when Host status is not up]* For better orientation in failed job's engine log [1], fence action for host fails at :46:12,842-04 engine learns it cannot connect storage to host at :46:16,105-04 The test itself add_master_storage_domain starts at ~ :46:13,753 (according to lago log). Could you please check this? Thanks [1] https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15829 [2] https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15829/artifa…

3 6

FYI: RAM needed to compile the engine
by Fedor Gavrilov 19 Sep '19

19 Sep '19

Hi, This is all out of curiosity and just FYI. I noticed that most recent engine master on CentOS 7.7 now requires about 8 GB of memory to compile. Otherwise it will fail during GWT part. 6 GB - not good enough. Strange thing is about a month ago it worked perfectly fine for me on 4 GB. Also, I am running it on VM, so old rule applies: it is 8 gigs starting memory, not max memory. I wonder if someone had similar experience. Fedor

1 0

CentOS 7.7 has been released: note it's not supported for oVirt 4.2
by Sandro Bonazzola 19 Sep '19

19 Sep '19

CentOS 7.7 has been released this week. Please note that CentOS 7.7 is not supported for oVirt 4.2 and older releases. If you want to upgrade to CentOS 7.7 please upgrade to oVirt 4.3 too. If you don't plan to upgrade to oVirt 4.3 please be sure your yum repo files points to http://mirror.centos.org/centos/7.6.1810/ instead of http://mirror.centos.org/centos/7/. The http://mirror.centos.org/centos/7/ URL is now pointing to http://mirror.centos.org/centos/7.7.1908/ so yum upgrade will bring you 7.7 content which may break your 4.2 installation. Thanks, -- 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.*

2 1

Removing big (hc-* and metrics) suits from OST's check-patch (How to make OST faster in CI)
by Barak Korren 19 Sep '19

19 Sep '19

If you have been using or monitoring any OST suits recently, you may have noticed we've been suffering from long delays in allocating CI hardware resources for running OST suits. I'd like to briefly discuss the reasons behind this, what are planning to do to resolve this and the implication of those actions for big suit owners. As you might know, we have moved a while ago from running OST suits each on its own dedicated server to running them inside containers managed by OpenShift. That had allowed us to run multiple OST suits on the same bare-metal host which in turn increased our overall capacity by 50% while still allowing us to free up hardware for accommodating the kubevirt project on our CI hardware. Our infrastructure is currently built in a way where we use the exact same POD specification (and therefore resource settings) for all suits. Making it more flexible at this point would require significant code changes we are not likely to make. What this means is that we need to make sure our PODs have enough resources to run the most demanding suits. It also means we waste some resources when running less demanding ones. Given the set of OST suits we have ATM, we sized our PODs to allocate 32Gibs of RAM. Given the servers we have, this means we can run 15 suits at a time in parallel. This was sufficient for a while, but given increasing demand, and the expectation for it to increase further once we introduce the patch gating features we've been working on, we must find a way to significantly increase our suit running capacity. We have measured the amount of RAM required by each suit and came to the conclusion that for the vast majority of suits, we could settle for PODs that allocate only 14Gibs of RAM. If we make that change, we would be able to run a total of 40 suits at a time, almost tripling our current capacity. The downside of making this change is that our STDCI V2 infrastructure will no longer be able to run suits that require more then 14Gib of RAM. This effectively means it would no longer be possible to run these suits from OST's check-patch job or from the OST manual job. The list of relevant suits that would be affected follows, the suit owners, as documented in the CI configuration, have be added as "to" recipients to the message: - hc-basic-suite-4.3 - hc-basic-suite-master - metrics-suite-4.3 Since we're aware people would still like to be able to work with the bigger suits, we will leverage the nightly suit invocation jobs to enable then to be run in the CI infra. We will support the following use cases: - *Periodically running the suit on the latest oVirt packages* - this will be done by the nightly job like it is done today - *Running the suit to test changes to the suit`s code* - while currently this is done automatically by check-patch, this would have to be done manually in the future by manually triggering the nightly job and setting the REFSPEC parameter to point to the examined patch - *Triggering the suit manually* - This would be done by triggering the suit-specific nightly job (as opposed to the general OST manual job) The patches listed below implement the changes outlined above: - 102757 <https://gerrit.ovirt.org/102757> nightly-system-tests: big suits -> big containers - 102771 <https://gerrit.ovirt.org/102771>: stdci: Drop `big` suits from check-patch We know that making the changes we presented will make things a little less convenient for users and maintainers of the big suits, but we believe the benefits of having vastly increased execution capacity for all other suits outweigh those shortcomings. We would like to hear all relevant comment and questions from the quite owners and other interested parties, especially is you think we should not carry out the changes we propose. Please take the time to respond on this thread, or on the linked patches. Thanks, -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

2 4

OST fails
by Vojtech Juranek 19 Sep '19

19 Sep '19

Hi, OST has started to fail during today, fails with unsatisfied rpm dependencies, e.g. + yum install --nogpgcheck --downloaddir=/dev/shm -y ntp net-snmp ovirt-engine ovirt-log-collector 'ovirt-engine-extension-aaa-ldap*' otopi-debug-plugins cronie Error: Package: rsyslog-mmjsonparse-8.24.0-38.el7.x86_64 (alocalsync) Requires: rsyslog = 8.24.0-38.el7 Installed: rsyslog-8.24.0-34.el7.x86_64 (installed) rsyslog = 8.24.0-34.el7 and many more, see [1] for more details. Any idea what's wrong? Thanks Vojta [1] https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5601/console

2 3

[User is not authorized to perform this action.]
by smidhunraj＠gmail.com 19 Sep '19

19 Sep '19

I am getting error as User is not authorized to perform this action.I am using oVirt api to manually attach a disk and snapshot to another virtual machine.This the code i used.The API i followed is '<disk_attachment> <active>true</active> <bootable>false</bootable> <interface>virtio</interface> <disk id="a94106b7-d348-4088-aaa1-5dfc46dc094e"> <snapshot id="6ecbb953-c4fb-4294-9988-e7cd2bd9b038"/> <description>My disk</description> <format>cow</format> <name>mydisk</name> </disk> </disk_attachment> ============================== The php code i have tried is ... public function attachSnapshotandActivateDisk( ) { $data = array(); $xmlStr = '<disk_attachment> <active>true</active> <bootable>false</bootable> <interface>virtio</interface> <disk id="a94106b7-d348-4088-aaa1-5dfc46dc094e"> <snapshot id="6ecbb953-c4fb-4294-9988-e7cd2bd9b038"/> <description>My disk</description> <format>cow</format> <name>mydisk</name> </disk> </disk_attachment> '; $curlParam = array( "url" => "vms/74a1a99f-87d1-4444-b394-f90e4f29f51f/diskattachments", "method" => "POST", "data" => $xmlStr ); // $text = print_r($curlParam, true); //echo "<script>console.log( 'curl Parameter".json_encode($text)."');</script>"; $data = $this->processCurlRequest($curlParam, "vm-create"); // if instance update failed if ($data['status'] != 'success') { Common::ovirtLog(array( "requestParam" => $curlParam, "responseParam" => $data, )); } // show the output of print_r function as a string // $text = print_r($data, true); echo $data['message']; die; echo "<script type='text/javascript'> console.log('checking the attach snapshot activate disk function diskid=" . json_encode($data) . "') </script>"; //Detach the disk // $this->detachSnapshotDisk() ; return $data; } Please help me.

2 1

vdsm has been tagged (v4.30.31)
by Milan Zamazal 19 Sep '19

19 Sep '19

4 5

how to login into ovirts particular virtualmachine from a remote client
by smidhunraj＠gmail.com 19 Sep '19

19 Sep '19

Is there any way i can login into the virtual machine in ovirt from my local machine.Please help me.

1 0

how to login into ovirts particular virtualmachine from a remote client
by smidhunraj＠gmail.com 19 Sep '19

19 Sep '19

Is there any way i can login into the virtual machine in ovirt from my local machine.Please help me.

1 0

How to use ovirt-imageio api for downloading snapshot to our localmachine.
by smidhunraj＠gmail.com 19 Sep '19

19 Sep '19

CAn anyone give me a working example of api on how to download snapshot to our local machine using ovirt using ovirt-imageio using api.Do we need to setup some certificate at our ovirt engine side.Please help me

1 0

[User is not authorized to perform this action.]
by smidhunraj＠gmail.com 18 Sep '19

18 Sep '19

I am getting error as User is not authorized to perform this action.I am using oVirt api to manually attach a disk and snapshot to another virtual machine.This the code i used.The API i followed is '<disk_attachment> <active>true</active> <bootable>false</bootable> <interface>virtio</interface> <disk id="a94106b7-d348-4088-aaa1-5dfc46dc094e"> <snapshot id="6ecbb953-c4fb-4294-9988-e7cd2bd9b038"/> <description>My disk</description> <format>cow</format> <name>mydisk</name> </disk> </disk_attachment> ============================== The php code i have tried is ... public function attachSnapshotandActivateDisk( ) { $data = array(); $xmlStr = '<disk_attachment> <active>true</active> <bootable>false</bootable> <interface>virtio</interface> <disk id="a94106b7-d348-4088-aaa1-5dfc46dc094e"> <snapshot id="6ecbb953-c4fb-4294-9988-e7cd2bd9b038"/> <description>My disk</description> <format>cow</format> <name>mydisk</name> </disk> </disk_attachment> '; $curlParam = array( "url" => "vms/74a1a99f-87d1-4444-b394-f90e4f29f51f/diskattachments", "method" => "POST", "data" => $xmlStr ); // $text = print_r($curlParam, true); //echo "<script>console.log( 'curl Parameter".json_encode($text)."');</script>"; $data = $this->processCurlRequest($curlParam, "vm-create"); // if instance update failed if ($data['status'] != 'success') { Common::ovirtLog(array( "requestParam" => $curlParam, "responseParam" => $data, )); } // show the output of print_r function as a string // $text = print_r($data, true); echo $data['message']; die; echo "<script type='text/javascript'> console.log('checking the attach snapshot activate disk function diskid=" . json_encode($data) . "') </script>"; //Detach the disk // $this->detachSnapshotDisk() ; return $data; } Please help me.

1 0

ovirt-release43-pre is not install able
by Dominik Holler 17 Sep '19

17 Sep '19

Hello, please note that yum install -y https://resources.ovirt.org/pub/yum-repo/ovirt-release43-pre.rpm yum install -y ovirt-host is currently failing with Error: Package: vdsm-4.30.30-1.el7.x86_64 (ovirt-4.3-pre) Requires: sanlock-python >= 3.7.3 Installing: sanlock-python-3.6.0-1.el7.x86_64 (base) sanlock-python = 3.6.0-1.el7 Error: Package: ovirt-hosted-engine-ha-2.3.5-1.el7.noarch (ovirt-4.3-pre) Requires: sanlock-python >= 3.7.3 Installing: sanlock-python-3.6.0-1.el7.x86_64 (base) sanlock-python = 3.6.0-1.el7 Error: Package: ovirt-hosted-engine-ha-2.3.5-1.el7.noarch (ovirt-4.3-pre) Requires: sanlock >= 3.7.3 Installing: sanlock-3.6.0-1.el7.x86_64 (base) sanlock = 3.6.0-1.el7 Is someone already fixing this? Dominik

2 1

the virtual machine crushed and I cant shutdown the vm successfully
by zhouhao＠vip.friendtimes.net 17 Sep '19

17 Sep '19

The trouble bothered me for a long time;Some times my vm will crush and I cant shutdown it,I had to reboot the ovirt-node to slove it; the vm's error below The ovirt-node's error below The vm's threading on the ovirt-node, the IO ratio is 100% and the vm's process change to defunct I can not kill it,every time I had to shutdown the ovirt-node on the engine website ,the vm's status always in the way to shutdown ,even if I wait for it for hours; It either failed or is shutting down and the "power off" cant shutdown the vm too. ---------------------------------------------------------------- The other infomation about my ovirt-node node-version： node hardware zhouhao(a)vip.friendtimes.net

2 2

[oVirt] [CQ weekly status] [13-09-2019]
by Dusan Fodor 14 Sep '19

14 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) No failure this week. *CQ-Master:* RED (#1) Last failure was on 12-09 was for ovirt-engine on adding storage domain. The issue is under investigation under thread "random failures for add_master_storage_domain". 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

[OST] Otopi error
by Ales Musil 12 Sep '19

12 Sep '19

Hi, I have seen otopi error in few last builds [1]: *04:18:56* Version: otopi-1.9.0_master (otopi-1.9.0-0.0.master.20190908102607.git6eb2c28.el7)*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.network.bridge.Plugin._detect_bridges" refers to a method name "ohosted.core.require.answerfile", but no method with this name exists*04:18:56* [ ERROR ] "before" parameter of method "otopi.plugins.gr_he_common.vm.boot_disk.Plugin._customization_ansible" refers to a method name "ohosted.configuration.ovf", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.vm.boot_disk.Plugin._customization_ansible" refers to a method name "ohosted.upgrade.check.spm.host", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.vm.cpu.Plugin._customization" refers to a method name "ohosted.configuration.ovf", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.vm.cpu.Plugin._customization" refers to a method name "ohosted.vm.cpu.model.customization", but no method with this name exists*04:18:56* [ ERROR ] "before" parameter of method "otopi.plugins.gr_he_common.vm.memory.Plugin._customization" refers to a method name "ohosted.vm.cpu.model.customization", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.vm.memory.Plugin._customization" refers to a method name "ohosted.configuration.ovf", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.vm.cloud_init.Plugin._customization" refers to a method name "ohosted.configuration.ovf", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.vm.cloud_init.Plugin._customization" refers to a method name "ohosted.upgrade.check.upgrade.ver", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.vm.mac.Plugin._customization" refers to a method name "ohosted.configuration.ovf", but no method with this name exists*04:18:56* [ ERROR ] "after" parameter of method "otopi.plugins.gr_he_common.core.misc.Plugin._persist_files_start" refers to a method name "ohosted.engine.ha.start", but no method with this name exists*04:18:56* [ ERROR ] Failed to execute stage 'Environment setup': Found bad "before" or "after" parameters Any idea what might be wrong? Thank you. [1] https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-ipv6-suite-master… -- Ales Musil Associate Software Engineer - RHV Network Red Hat EMEA <https://www.redhat.com> amusil(a)redhat.com IM: amusil <https://red.ht/sig>

2 1

VM crushed and cant shutdown successfully,I shoud to reboot the ovirt-node machine
by zhouhao＠vip.friendtimes.net 12 Sep '19

12 Sep '19

VM crushed and cant shutdown successfully,It always on the way to shutdown，even if I wait it for 10 hours；Everytimes I shoud to reboot the ovirt-node machine This comes up 4 times, It appes both on the ovirt-noe 4.3 and 4.2; This bug appers when my VM is running at high load（seems memory and disk's w/r） My storage domain is local on host; When the bug appers,it could cost my node's io,looks like the picture below；But sometimes it will not The vm's threading on the ovirt-node, the IO ratio is 100% Everytime the vm's process will change to defunct I can not kill it,I had to shutdown the ovirt-node on the engine website ,the vm's status always in the way to shutdown ,even if I wait for it for hours; It either failed or is shutting down and the "power off" cant shutdown the vm too. the vm's error below The ovirt-node's error below ---------------------------------------------------------------- The other infomation about my ovirt-node node-version： node hardware zhouhao(a)vip.friendtimes.net

1 0

ovirt-vmconsole package issues
by Marcin Sobczyk 11 Sep '19

11 Sep '19

Hi, we get a lot of failures in the CI for el7 and fc29 regarding this package since this morning, i.e. for fc29: <https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa…>[2019-09-11T07:55:42.107Z] [MIRROR] ovirt-vmconsole-1.0.7-3.fc29.noarch.rpm: Interrupted by header callback: Server reports Content-Length: 38712 but expected size is: 38804 <https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa…>[2019-09-11T07:55:42.107Z] [MIRROR] ovirt-vmconsole-1.0.7-3.fc29.noarch.rpm: Interrupted by header callback: Server reports Content-Length: 38712 but expected size is: 38804 <https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa…>[2019-09-11T07:55:42.107Z] [MIRROR] ovirt-vmconsole-1.0.7-3.fc29.noarch.rpm: Interrupted by header callback: Server reports Content-Length: 38712 but expected size is: 38804 <https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa…>[2019-09-11T07:55:42.107Z] [MIRROR] ovirt-vmconsole-1.0.7-3.fc29.noarch.rpm: Interrupted by header callback: Server reports Content-Length: 38712 but expected size is: 38804 <https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa…>[2019-09-11T07:55:42.107Z] [FAILED] ovirt-vmconsole-1.0.7-3.fc29.noarch.rpm: No more mirrors to try - All mirrors were already tried without success <https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa…>[2019-09-11T07:55:42.107Z] Error: Error downloading packages: <https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa…>[2019-09-11T07:55:42.107Z] Cannot download noarch/ovirt-vmconsole-1.0.7-3.fc29.noarch.rpm: All mirrors were tried Can someone take a look at this? Thanks, Marcin

3 2

Change Data Centre type from Local to Shared and vice versa
by scott.fitzgerald＠oracle.com 11 Sep '19

11 Sep '19

Hi all, How does one change a Data Centre type between Local/Shared through the SDK? Assume it's done through the systemService, but can't seem to find it. Cheers.

3 7

Reinitialize Data Center with corrupted Master Domain
by scott.fitzgerald＠oracle.com 11 Sep '19

11 Sep '19

Hi all, In the system I currently have a Data Center with a corrupted Master Domain, and a spare, unattached Domain. How do I use the SDK to reinitialize the Data Center by attaching the unattached Domain? Simply reattaching it doesn't seem to register as a proper re initialization, despite the system showing an active status for the data center after the attachment. Cheers.

2 2

[VDSM] storage python 3 tests status
by Nir Soffer 10 Sep '19

10 Sep '19

Sharing progress on python 3 work. ## 2 weeks ago git checkout @{two.weeks.ago} tox -e storage-py37 ... 1448 passed, 103 skipped, 100 deselected, 322 xfailed, 236 warnings in 71.40 seconds ## Today git checkout tox -e storage-py37 ... 1643 passed, 103 skipped, 100 deselected, 105 xfailed, 82 xpassed, 107 warnings in 79.72 seconds Change: *passed: +195* *skips: 0* *xfail: -217* *xpass: +107* *warnings: -129* ## XPASS 107 xpass are most likely easy fix, just remove the xfail() mark from the test or parameter. Patches should not introduce new XPASS, you should remove all xfail() marks that a patch fixes. To test that your patch do not introduce new XPASS, add this option to tox.ini: [pytest] xfail_strict = True This converts XPASS to FAIL. These modules need to be fixed: $ egrep '^storage.+_test.py.+X' storage-py37.out storage/filevolume_test.py ...XXXxXXXXxXXX [ 19%] storage/formatconverter_test.py XXXXXxxss [ 20%] storage/merge_test.py XXXXXXxxxxXXxXxxxxxXxxxxxx [ 38%] storage/nbd_test.py ssssssssssssX. [ 49%] storage/sd_manifest_test.py XXXXXXXXXxxxxxxxxxxxxxxxxxxxxxxx............ [ 65%] storage/sdm_amend_volume_test.py xXxXxXxX [ 66%] storage/sdm_copy_data_test.py xXXxxxxXXXXXxxxXXXxxXXxxXXx [ 67%] storage/sdm_merge_test.py xxxxXXX [ 79%] storage/sdm_update_volume_test.py xXxXxxXXxxXXxXxXxXxX....... [ 81%] storage/testlib_test.py xXXXxxXXXXXXXXxxxxxxxxxxxxxXxXxXxX.......... [ 87%] storage/volume_metadata_test.py ..........................X............. [ 90%] ## xfail We must fix these xfail before we can run OST. If we start running OST we will waste days debugging OST. Debugging failing tests is 1000X times faster. $ egrep '^storage.+_test.py.+x' storage-py37.out storage/blocksd_test.py ........x..........sssssssssss............ [ 4%] storage/blockvolume_test.py ...........xxxxxxxxx [ 5%] storage/fileutil_test.py ..xx....ss............................ [ 19%] storage/filevolume_test.py ...XXXxXXXXxXXX [ 19%] storage/formatconverter_test.py XXXXXxxss [ 20%] storage/merge_test.py XXXXXXxxxxXXxXxxxxxXxxxxxx [ 38%] storage/sd_manifest_test.py XXXXXXXXXxxxxxxxxxxxxxxxxxxxxxxx............ [ 65%] storage/sdm_amend_volume_test.py xXxXxXxX [ 66%] storage/sdm_copy_data_test.py xXXxxxxXXXXXxxxXXXxxXXxxXXx [ 67%] storage/sdm_merge_test.py xxxxXXX [ 79%] storage/sdm_update_volume_test.py xXxXxxXXxxXXxXxXxXxX....... [ 81%] storage/testlib_test.py xXXXxxXXXXXXXXxxxxxxxxxxxxxXxXxXxX.......... [ 87%] ## Skips Skips should be used only when test cannot run on specific environment, but I think we have some wrong skips that should have been xfail. $ egrep '^storage.+_test.py.+s' storage-py37.out storage/backends_test.py ss [ 2%] storage/blockdev_test.py ssss....s [ 2%] storage/blocksd_test.py ........x..........sssssssssss............ [ 4%] storage/devicemapper_test.py s. [ 9%] storage/fileutil_test.py ..xx....ss............................ [ 19%] storage/formatconverter_test.py XXXXXxxss [ 20%] storage/loopback_test.py ssss [ 31%] storage/lvm_test.py ....................ssssssssssssssssssss [ 33%] storage/lvmfilter_test.py .....ss.......... [ 35%] storage/managedvolume_test.py ssssssssssssssssss.... [ 36%] storage/misc_test.py .................sssssssss...............ssss...... [ 41%] storage/mount_test.py .........ss........ssssss [ 47%] storage/nbd_test.py ssssssssssssX. [ 49%] storage/udev_multipath_test.py .......................s [ 88%] ## Warnings See "warnings summary" in pytest output. Looks less useful, report issues in packages we use instead of issues in our code. But this may be an issue using old versions of packages. See attached results created with: tox -e storage-py37 > storage-py37.out 2>&1 Nir

2 3

oVirt conference 2019 - Rome - October 4th
by Sandro Bonazzola 10 Sep '19

10 Sep '19

The oVirt Italian community <https://www.facebook.com/groups/ovirt.italia/> and Extraordy <https://www.extraordy.com/> in collaboration with Red Hat <https://www.redhat.com>, Oracle <https://www.oracle.com>, and Storware <https://storware.eu/> are pleased to invite you at oVirt Conference 2019 in Rome on October 4th 2019! Tickets are available at https://www.eventbrite.it/e/biglietti-ovirt-conference-2019-innovate-the-da… Thanks -- 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

Ovirt Manager - FATAL: the database system is in recovery mode
by Sameer Sardar 10 Sep '19

10 Sep '19

PACKAGE_NAME="ovirt-engine" PACKAGE_VERSION="3.6.2.6" PACKAGE_DISPLAY_VERSION="3.6.2.6-1.el6" OPERATING SYSTEM="Centos 6.7" Its been running error-free for over 3 years now. Over the past few weeks, The Ovirt manager application has been frequently losing connection with its own database residing on the same server. It is throwing up errors saying: “Caused by org.postgresql.util.PSQLException: FATAL: the database system is in recovery mode”. The only means we have found to recover from this is to hard reboot the server, after which it works fine for a couple of days before throwing up these errors again. Here are some logs : Caused by: org.postgresql.util.PSQLException: FATAL: the database system is in recovery mode at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:293) at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:108) at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66) at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:125) at org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30) at org.postgresql.jdbc3g.AbstractJdbc3gConnection.<init>(AbstractJdbc3gConnection.java:22) at org.postgresql.jdbc4.AbstractJdbc4Connection.<init>(AbstractJdbc4Connection.java:32) at org.postgresql.jdbc4.Jdbc4Connection.<init>(Jdbc4Connection.java:24) at org.postgresql.Driver.makeConnection(Driver.java:393) at org.postgresql.Driver.connect(Driver.java:267) at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:322)

3 4

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

09 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.2*: NOT RELEVANT This CQ is not followed anymore, since it's about to be decommissioned. *CQ-4.3*: YELLOW (#1) Last failure was on 06-09 for vdsm in host installation. It was caused by missing package and solved soon after. *CQ-Master:* YELLOW (#1) Last failure was on 05-09 was random one-time failure on adding storage domain. Current running jobs for 4.2 [1], 4.3 [2] and master [3] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -4.2_change-queue-tester/ [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt -4.3_change-queue-tester/ [3] 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/

3 2

Error running engine-setup in dev-env on FC29
by Martin Perina 09 Sep '19

09 Sep '19

Hi, has anyone seen below error when running engine-setup in dev env on FC29? [ INFO ] Generating post install configuration file '/home/mperina/ovirt-engine/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf' [ ERROR ] Failed to execute stage 'Misc configuration': a bytes-like object is required, not 'str' [ INFO ] Rolling back database schema [ INFO ] Clearing Engine database engine [ INFO ] Stage: Clean up Log file is located at /home/mperina/ovirt-engine/var/log/ovirt-engine/setup/ovirt-engine-setup-20190909105257-dh2le0.log [ INFO ] Generating answer file '/home/mperina/ovirt-engine/var/lib/ovirt-engine/setup/answers/20190909105355-setup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Execution of setup failed Following exception is raised in the setup log: 2019-09-09 10:53:49,357+0200 DEBUG otopi.context context._executeMethod:127 Stage misc METHOD otopi.plugins.ovirt_engine_common.base.core.postinstall.Plugin._misc 2019-09-09 10:53:49,357+0200 INFO otopi.plugins.ovirt_engine_common.base.core.postinstall postinstall._misc:60 Generating post install configuration file '/home/mperina/ovirt-engine/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf' 2019-09-09 10:53:49,358+0200 DEBUG otopi.transaction transaction._prepare:61 preparing 'File transaction for '/home/mperina/ovirt-engine/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf'' 2019-09-09 10:53:49,358+0200 DEBUG otopi.filetransaction filetransaction.prepare:184 file '/home/mperina/ovirt-engine/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf' missing 2019-09-09 10:53:49,358+0200 DEBUG otopi.transaction transaction._prepare:66 exception during prepare phase FATAL Internal error (main): a bytes-like object is required, not 'str' Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/otopi/__main__.py", line 83, in main installer.execute() File "/usr/lib/python3.7/site-packages/otopi/main.py", line 151, in execute self.context.runSequence() File "/usr/lib/python3.7/site-packages/otopi/context.py", line 643, in runSequence util.raiseExceptionInformation(infos[0]) File "/usr/lib/python3.7/site-packages/otopi/util.py", line 84, in raiseExceptionInformation raise info[1].with_traceback(info[2]) File "/usr/lib/python3.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/home/mperina/ovirt-engine/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-common/base/core/postinstall.py", line 98, in _misc otopicons.CoreEnv.MODIFIED_FILES File "/usr/lib/python3.7/site-packages/otopi/transaction.py", line 106, in append self._prepare(element=element) File "/usr/lib/python3.7/site-packages/otopi/transaction.py", line 62, in _prepare element.prepare() File "/usr/lib/python3.7/site-packages/otopi/filetransaction.py", line 253, in prepare os.write(fd, self._content) TypeError: a bytes-like object is required, not 'str' It's latest master, all packages updated in the morning. Thanks, M. -- Martin Perina Manager, Software Engineering Red Hat Czech s.r.o.

3 5

chanking mkIsoFs path
by Dan Kenigsberg 06 Sep '19

06 Sep '19

I bumped by accident on https://gerrit.ovirt.org/#/c/102698/ py3: mkimage: Remove md5 part in getFileName and I don't think it is right: if a VM is created in a 4.3 cluster and then migrated to a 4.4 cluster, qemu would not find the ISO image where it expects it, and it would break. I don't recall WHY we had md5 included into the path. It may well has been a mistake. I just do not see a (easy) backward-compatible way to drop it now.

3 2

OST is broken since this morning - looks like infra issue
by Nir Soffer 05 Sep '19

05 Sep '19

The last successful build was today at 08:10: Since then all builds fail very early with the error below - which is not related to oVirt. Removing image: sha256:f8e5aa8e979155e074411bfef9adade6cdcdf3a5a2eb1d5ad2dbf0288d585ffa, force=True Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/docker/api/client.py", line 222, in _raise_for_status response.raise_for_status() File "/usr/lib/python3.6/site-packages/requests/models.py", line 893, in raise_for_status raise HTTPError(http_error_msg, response=self) requests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localunixsocket/v1.30/images/sha256:f8e5aa8e979155e074411bfef9adade6cdcdf3a5a2eb1d5ad2dbf0288d585ffa?force=True&noprune=False During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/jenkins/workspace/ovirt-system-tests_manual/jenkins/scripts/docker_cleanup.py", line 349, in <module> main() File "/home/jenkins/workspace/ovirt-system-tests_manual/jenkins/scripts/docker_cleanup.py", line 37, in main safe_image_cleanup(client, whitelisted_repos) File "/home/jenkins/workspace/ovirt-system-tests_manual/jenkins/scripts/docker_cleanup.py", line 107, in safe_image_cleanup _safe_rm(client, parent) File "/home/jenkins/workspace/ovirt-system-tests_manual/jenkins/scripts/docker_cleanup.py", line 329, in _safe_rm client.images.remove(image_id, force=force) File "/usr/lib/python3.6/site-packages/docker/models/images.py", line 288, in remove self.client.api.remove_image(*args, **kwargs) File "/usr/lib/python3.6/site-packages/docker/utils/decorators.py", line 19, in wrapped return f(self, resource_id, *args, **kwargs) File "/usr/lib/python3.6/site-packages/docker/api/image.py", line 481, in remove_image return self._result(res, True) File "/usr/lib/python3.6/site-packages/docker/api/client.py", line 228, in _result self._raise_for_status(response) File "/usr/lib/python3.6/site-packages/docker/api/client.py", line 224, in _raise_for_status raise create_api_error_from_http_exception(e) File "/usr/lib/python3.6/site-packages/docker/errors.py", line 31, in create_api_error_from_http_exception raise cls(e, response=response, explanation=explanation) docker.errors.NotFound: 404 Client Error: Not Found ("reference does not exist") Aborting. Build step 'Execute shell' marked build as failure x [image: Failed > Console Output] <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5542/console> #5542 <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5542/> Sep 5, 2019 3:02 PM <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5542/> [image: Failed > Console Output] <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5541/console> #5541 <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5541/> Sep 5, 2019 3:02 PM <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5541/> [image: Failed > Console Output] <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5540/console> #5540 <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5540/> Sep 5, 2019 3:01 PM <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5540/> [image: Failed > Console Output] <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5539/console> #5539 <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5539/> Sep 5, 2019 2:13 PM <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5539/> [image: Failed > Console Output] <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5538/console> #5538 <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5538/> Sep 5, 2019 1:58 PM <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5538/> [image: Failed > Console Output] <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5537/console> #5537 <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5537/> Sep 5, 2019 1:50 PM <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5537/> [image: Failed > Console Output] <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5536/console> #5536 <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5536/> Sep 5, 2019 10:21 AM <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5536/> [image: x] <http://jenkins.ovirt.org/job/ovirt-system-tests_manual/jobConfigHistory/sho…> [image: Success > Console Output] <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5535/console> #5535 <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5535/> Sep 5, 2019 8:10 AM <https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5535/>

1 0

'Misc configuration' failed in engine-setup
by Shmuel Melamud 05 Sep '19

05 Sep '19

Hi! I've tried several minutes ago to perform engine-setup on the latest master and it failed with the message: [ INFO ] Stage: Misc configuration [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 2] No such file or directory: '/etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf' Anybody knows what may cause the error? Shmuel

3 4

OST fails in verify_backup_snapshot_removed
by Yedidyah Bar David 04 Sep '19

04 Sep '19

Hi all, OST manual job failed for me a few times recently in 004_basic_sanity.verify_backup_snapshot_removed , last two (both with what I think are unrelated changes) are: 1. https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… with the copyright notices patches to the engine: https://gerrit.ovirt.org/97698 2. https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… with the unicode patches to the engine and to otopi: https://gerrit.ovirt.org/102936 https://gerrit.ovirt.org/102938 In job console, you can see that remove_backup_vm_and_backup_snapshot finished successfully, and several minutes latee verify_backup_snapshot_removed fails with a timeout. In between, engine.log has several ERRORs, e.g.: https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… 2019-09-04 11:05:31,271-04 ERROR [org.ovirt.engine.core.bll.storage.disk.image.DestroyImageCommand] (EE-ManagedThreadFactory-engine-Thread-354) [e55e5d43-c168-42b4-9b80-e0cd2b8405bb] Ending command 'org.ovirt.engine.core.bll.storage.disk.image.DestroyImageCommand' with failure. No idea if that's related, didn't dig deeper. Any clue? Is this a known issue? Thanks and best regards, -- Didi

2 1

Detach Storage Domain
by scott.fitzgerald＠oracle.com 04 Sep '19

04 Sep '19

Hi, I'm looking to use the SDK to detach a Non Master Storage Domain from a given Data Centre, without removing it from the system, ie it goes to Unattached mode. I have set the Domain to Maintenance, but can't see an obvious option for detaching it, except for removing it from the system entirely. Any advice is appreciated.

2 2

ovirt-engine has been tagged (ovirt-engine-4.3.6.5)
by Tal Nisan 04 Sep '19

04 Sep '19

1 0

the virtual machine crushed and I cant shutdown the vm successfully
by zhouhao＠vip.friendtimes.net 04 Sep '19

04 Sep '19

Dear ovirt developers: The trouble bothered me for a long time;Some times my vm will crush and I cant shutdown it,I had to reboot the ovirt-node to slove it; the vm's error below The ovirt-node's error below The vm's threading on the ovirt-node, the IO ratio is 100% and the vm's process change to defunct I can not kill it,every time I had to shutdown the ovirt-node on the engine website ,the vm's status always in the way to shutdown ,even if I wait for it for hours; It either failed or is shutting down and the "power off" cant shutdown the vm too. ---------------------------------------------------------------- The other infomation about my ovirt-node node-version： node hardware zhouhao(a)vip.friendtimes.net

1 0

the virtual machine crushed and I cant shutdown the vm successfully
by zhouhao＠vip.friendtimes.net 04 Sep '19

04 Sep '19

Dear ovirt developers: The trouble bothered me for a long time;Some times my vm will crush and I cant shutdown it,I had to reboot the ovirt-node to slove it; the vm's error below The ovirt-node's error below The vm's threading on the ovirt-node, the IO ratio is 100% and the vm's process change to defunct I can not kill it,every time I had to shutdown the ovirt-node on the engine website ,the vm's status always in the way to shutdown ,even if I wait for it for hours; It either failed or is shutting down and the "power off" cant shutdown the vm too. ---------------------------------------------------------------- The other infomation about my ovirt-node node-version： node hardware zhouhao(a)vip.friendtimes.net

1 0

URGENT - ovirt-engine master is failing for the past 9 days
by Dafna Ron 03 Sep '19

03 Sep '19

Hi, We have been failing CQ master for project ovirt-engine for the past 9 days. this was reported last week and we have not yet seen a fix for this issue. the patch reported by CQ is https://gerrit.ovirt.org/#/c/101913/10 - core: Change CPU config to secure/insecure concept logs for latest failure can be found here: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15638/artifac… Error: 2019-09-01 06:31:17,248-04 INFO [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-1) [174bc463-9a98-441f-ad14-4d97fefde4fa] Running command: UpdateClusterCommand internal: false. Entities affected : ID: 0407bc06-4bef-4c47-99e1-0e42f9ced996 Type: ClusterAction group EDIT_CLUSTER_CONFIGURATION with role type ADMIN 2019-09-01 06:31:17,263-04 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [174bc463-9a98-441f-ad14-4d97fefde4fa] EVENT_ID: CLUSTER_UPDATE_CPU_WHEN_DEPRECATED(9,029), Modified the CPU Type to Intel Haswell-noTSX Family when upgrading the Compatibility Version of Cluster test-cluster because the previous CPU Type was deprecated. 2019-09-01 06:31:17,319-04 WARN [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [18fd7817] Validation of action 'UpdateVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__VM,ACTION_TYPE_FAILED_ILLEGAL_OS_TYPE_IS_NOT_SUPPORTED_BY_ARCHITECTURE_TYPE 2019-09-01 06:31:17,329-04 WARN [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [62694a6a] Validation of action 'UpdateVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__VM,ACTION_TYPE_FAILED_ILLEGAL_OS_TYPE_IS_NOT_SUPPORTED_BY_ARCHITECTURE_TYPE 2019-09-01 06:31:17,334-04 WARN [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [10e41cd3] Validation of action 'UpdateVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__VM,ACTION_TYPE_FAILED_ILLEGAL_OS_TYPE_IS_NOT_SUPPORTED_BY_ARCHITECTURE_TYPE 2019-09-01 06:31:17,345-04 WARN [org.ovirt.engine.core.bll.UpdateVmTemplateCommand] (default task-1) [26a471dd] Validation of action 'UpdateVmTemplate' failed for user admin@internal-authz. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__VM_TEMPLATE,VMT_CANNOT_UPDATE_ILLEGAL_FIELD 2019-09-01 06:31:17,352-04 WARN [org.ovirt.engine.core.bll.UpdateVmTemplateCommand] (default task-1) [32fd89b5] Validation of action 'UpdateVmTemplate' failed for user admin@internal-authz. Reasons: VAR__ACTION__UPDATE,VAR__TYPE__VM_TEMPLATE,VMT_CANNOT_UPDATE_ILLEGAL_FIELD 2019-09-01 06:31:17,363-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [32fd89b5] EVENT_ID: CLUSTER_CANNOT_UPDATE_VM_COMPATIBILITY_VERSION(12,005), Cannot update compatibility version of Vm/Template: [vm-with-iface], Message: [No Message] 2019-09-01 06:31:17,371-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [32fd89b5] EVENT_ID: CLUSTER_CANNOT_UPDATE_VM_COMPATIBILITY_VERSION(12,005), Cannot update compatibility version of Vm/Template: [vm-with-iface-template], Message: [No Message] 2019-09-01 06:31:17,380-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [32fd89b5] EVENT_ID: CLUSTER_CANNOT_UPDATE_VM_COMPATIBILITY_VERSION(12,005), Cannot update compatibility version of Vm/Template: [vm0], Message: [No Message] 2019-09-01 06:31:17,388-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [32fd89b5] EVENT_ID: CLUSTER_CANNOT_UPDATE_VM_COMPATIBILITY_VERSION(12,005), Cannot update compatibility version of Vm/Template: [vm1], Message: [No Message] 2019-09-01 06:31:17,405-04 INFO [org.ovirt.engine.core.bll.CommandCompensator] (default task-1) [32fd89b5] Command [id=50898f00-4956-484a-94ff-f273adc2e93e]: Compensating UPDATED_ONLY_ENTITY of org.ovirt.engine.core.common.businessentities.Cluster; snapshot: Cluster [test-cluster]. 2019-09-01 06:31:17,422-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [32fd89b5] EVENT_ID: USER_UPDATE_CLUSTER_FAILED(812), Failed to update Host cluster (User: admin@internal-authz) 2019-09-01 06:31:17,422-04 INFO [org.ovirt.engine.core.bll.UpdateClusterCommand] (default task-1) [32fd89b5] Lock freed to object 'EngineLock:{exclusiveLocks='[5d3b2f0f-f05f-41c6-b61a-c517704f79fd=TEMPLATE, 728f5530-4e34-4c92-beef-ca494ec104b9=TEMPLATE]', sharedLocks='[a107316a-a961-403f-adb2-d01f22f0b8f1=VM, dc3a2ad8-6019-4e00-85e5-d9fba7390d4f=VM, 6348722f-61ae-40be-a2b8-bd9d086b06dc=VM]'}' 2019-09-01 06:31:17,424-04 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-1) [] Operation Failed: [Update of cluster compatibility version failed because there are VMs/Templates [vm-with-iface, vm-with-iface-template, vm0, vm1] with incorrect configuration. To fix the issue, please go to each of them, edit, change the Custom Compatibility Version of the VM/Template to the cluster level you want to update the cluster to and press OK. If the save does not pass, fix the dialog validation. After successful cluster update, you can revert your Custom Compatibility Version change.] (END)

3 6

unicode_literrals vs "u''" vs six.text_type
by Yedidyah Bar David 02 Sep '19

02 Sep '19

Hi all, That's a "sub-thread" of "unicode sandwich in otopi/engine-setup". I was recommended to use 'six.text_type() over "u''". I did read [1], and eventually decided that my own preference is to just add "u" prefix. Reasoning is inside [1]. Do people have different preferences/reasoning they want to share? Do people think we should have project-wide policy re this? Personally, I do not see the big advantage of adding "six.text_type()" (15 chars) instead of a single "u". I do see where it can be useful, but not as a very long replacement, IMO, for "u", or for unicode_literrals. Thanks and best regards, [1] http://python-future.org/unicode_literals.html -- Didi

2 5