February 2019 - Devel - oVirt List Archives

ovirt-engine-sdk-go: Integration with TravisCI to support pushing auto-generated codes
by Joey Ma 22 Feb '19

22 Feb '19

Hi all, With the generous help of several nice guys, currently the Go SDK related projects, oVirt/ovirt-engine-sdk-go and oVirt/go-ovirt, are already available under oVirt org, and the integration of oVirt/ovirt-engine-sdk-go with oVirt STD-CI is also completed [1]. Sincerely thank you to everyone. While there is still an issue left that we need a proper solution to integrate oVirt/ovirt-engine-sdk-go with TravisCI which could push the auto-generated codes into oVirt/go-ovirt. Previously I adopted my personal github access token which is stored encrypted [2] to work it out. But as it's been under oVirt community, we need a more regular way to make this. As @Evgheni <ederevea(a)redhat.com> suggested, maybe a new access token from a dedicated github account or via the Jenkins job will work? Any one could help? Any insights into this would be appreciated and thanks in advance. Best regards, Joey [1]: https://github.com/oVirt/ovirt-engine-sdk-go/pull/144 [2]: https://docs.travis-ci.com/user/environment-variables#defining-encrypted-va…

2 5

[VDSM] check-patch job fail - Cannot download x86_64/ovirt-imageio-common-1.5.0-0.201901061027.gita4be4ca.fc28.x86_64.rpm: All mirrors were tried
by Nir Soffer 21 Feb '19

21 Feb '19

In this buidl: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/3035/artifact/ci_bu… 2 sub stages failed: This failed without generating any log, but we can see the error in the blue ocean interface: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/3035//artifact/chec… https://jenkins.ovirt.org/blue/organizations/jenkins/vdsm_standard-check-pa… This failed with this log: https://jenkins.ovirt.org/job/vdsm_standard-check-patch/3035//artifact/chec… Both failed becasue: Cannot download x86_64/ovirt-imageio-common-1.5.0-0.201901061027.gita4be4ca.fc28.x86_64.rpm: All mirrors were tried The other sub stages succeeded, and building the patch on top succeeded: https://gerrit.ovirt.org/c/97847 Looks like temporary error, failing to find a package from tested repository? How can we prevent these errors? Nir

2 3

ovirt-engine has been tagged (ovirt-engine-4.2.8.5)
by Tal Nisan 21 Feb '19

21 Feb '19

1 0

oVirt 4.3.1 test day
by Sandro Bonazzola 20 Feb '19

20 Feb '19

Hi, We are planning to release the first candidate of 4.3.1 on February 20th[1] and the final release on February 26th. Please join us testing this release candidate right after it will be announced! We are going to coordinate the testing effort with a public Trello board at https://trello.com/b/5ZNJgPC3 You'll find instructions on how to use the board there. If you have an environment dedicated to testing, remember you can setup a few VMs and test the deployment with nested virtualization. To ease the setup of such environment you can use Lago ( https://github.com/lago-project) The oVirt team will monitor the Trello board, the #ovirt IRC channel on irc.oftc.net server and the users(a)ovirt.org mailing list to assist with the testing. [1] https://www.ovirt.org/develop/release-management/releases/4.3.z/release-man… -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

2 3

[ANN] oVirt 4.3.1 First Release Candidate is now available
by Sandro Bonazzola 20 Feb '19

20 Feb '19

The oVirt Project is pleased to announce the availability of the oVirt 4.3.1 First Release Candidate, as of February 20th, 2019. This update is a release candidate of the first in a series of stabilization updates to the 4.3 series. This is pre-release software. This pre-release should not to be used in production. This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later * oVirt Node 4.3 (available for x86_64 only) Experimental tech preview for x86_64 and s390x architectures for Fedora 28 is also included. See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is available for EL7 only - oVirt Node is available for EL7 only [2] - Fedora 28 based appliance and node couldn't be built due to a bug in Lorax (the tool used to build the images) affecting Fedora 28. Additional Resources: * Read more about the oVirt 4.3.1 release highlights: http://www.ovirt.org/release/4.3.1/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/4.3.1/ [2] http://resources.ovirt.org/pub/ovirt-4.3-pre/iso/ -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

Vdsm: Intention to make ovirt-4.3 branch
by Milan Zamazal 20 Feb '19

20 Feb '19

Hi, I'm going to make ovirt-4.3 Vdsm branch next week. If there are any very important reasons not to make it, please let me know. Thanks, Milan

4 8

ovirt-engine has been tagged (ovirt-engine-4.3.1.1)
by Tal Nisan 20 Feb '19

20 Feb '19

2 2

ovirt-engine has been tagged (ovirt-engine-4.3.1)
by Tal Nisan 19 Feb '19

19 Feb '19

7 14

ovirt-engine has been tagged (ovirt-engine-4.2.8.4)
by Tal Nisan 19 Feb '19

19 Feb '19

1 0

Re: Query regarding initial size value given to rest api for creating QCOW2 disk
by Himani Vaidya 19 Feb '19

19 Feb '19

Hi Nir, Daniel And Devel Guys, We have query regarding initial size attribute that we need specify in create disk API for qcow2 format. As per our discussions with you all it came up that we need initial size to be specified at qcow2 disk creation/restore so that that much size is preallocated. Based on that we specify request body for qcow2 to /ovirt-engine/api/disks as follows:- <disk> <storage_domains> <storage_domain id="aaaa"/> </storage_domains> <name>mydisk</name> <provisioned_size>xxxx</provisioned_size> <initial_size>yyyy<initial_size> <format>cow</format> </disk> Consider provisioned_size = 1 GB (Guest offset)(raw thick disk) Initial_size = > 1GB Initial_size > provisioned_size Also as per disk struct specified in http://ovirt.github.io/ovirt-engine-api-model/4.3/#types/disk Initial_size and provisioned size both are different attributes .Therefore these need to specified differently as per above request body. But unfortunately we saw it fails at write offset greater that provisioned size at data restore time. It doesn't consider initial_size attribute specified in request body only considers provisioned size . Can you please confirm whether for COW format what attributes and actual values(consider 1GB example) are needed in request body of create disk API /ovirt-engine/api/disks ? Thanks Himani Vaidya From: Mohammed Eliyas Shaikh Sent: Thursday, January 31, 2019 8:39 PM To: Daniel Erez <derez(a)redhat.com>; Nir Soffer <nsoffer(a)redhat.com> Cc: pchavva(a)redhat.com; Suchitra Herwadkar <Suchitra.Herwadkar(a)veritas.com>; Abhay Marode <Abhay.Marode(a)veritas.com>; DL-VTAS-ENG-NBU-Midas <DL-VTAS-ENG-NBU-Midas(a)veritas.com>; Himani Vaidya <Himani.Vaidya(a)veritas.com> Subject: RE: Query regarding initial size for QCOW2 file restore Hi Pavan, Can we get direct number of Nir / Daniel to check if they are available for a short call now? Thanks, Mohammed Eliyas. From: Mohammed Eliyas Shaikh Sent: Thursday, January 31, 2019 1:39 PM To: Daniel Erez <derez(a)redhat.com<mailto:derez@redhat.com>>; Nir Soffer <nsoffer(a)redhat.com<mailto:nsoffer@redhat.com>> Cc: pchavva(a)redhat.com<mailto:pchavva@redhat.com>; Suchitra Herwadkar <Suchitra.Herwadkar(a)veritas.com<mailto:Suchitra.Herwadkar@veritas.com>>; Abhay Marode <Abhay.Marode(a)veritas.com<mailto:Abhay.Marode@veritas.com>>; DL-VTAS-ENG-NBU-Midas <DL-VTAS-ENG-NBU-Midas(a)veritas.com<mailto:DL-VTAS-ENG-NBU-Midas@veritas.com>>; Himani Vaidya <Himani.Vaidya(a)veritas.com<mailto:Himani.Vaidya@veritas.com>> Subject: Query regarding initial size for QCOW2 file restore Hi Nir and Daniel, We had a few questions around restoring a qcow2 file to RHV. We plan to support restoring a qcow2 file to RHV. The source of the backups could be from RAW thin/thick or qcow2. When restoring qcow2 we need to provide an initial size. The backup image being restored will have guest data in fragments. When writing these fragments into the qcow2 file we would need to pad them to the qcow2 cluster boundary for every fragment. When providing the initial size to RHV we should have included the amount of padding we would need for every fragment and this would be difficult to get upfront when the qcow2 file is being created at restore time. It will be a function of the guest data fragmentation which would be difficult to get upfront at the start of the restore. We would like to check if there is an easy way around this situation from the RHV side. 1. Can we make the initial size requirement optional when creating a qcow2 file? 2. If not then * Can we write beyond the initial size we provided when creating the file? * Can we use the provisioned size of the virtual disk as the initial size of the qcow2 file (after adding size for headers) and then truncate the file to its actual size after writing the file completely. Though we could run into cases where customers don't have enough space for the provisioned size. Any other ideas to work around this initial size requirement. Thanks, Himani and Mohammed Eliyas.

1 0