ovirt-engine-sdk-go: Integration with TravisCI to support pushing auto-generated codes
by Joey Ma
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-...
5 years, 10 months
[ANN] oVirt 4.3.1 First Release Candidate is now available
by Sandro Bonazzola
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>
5 years, 10 months
Vdsm: Intention to make ovirt-4.3 branch
by Milan Zamazal
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
5 years, 10 months
Re: Query regarding initial size value given to rest api for creating QCOW2 disk
by Himani Vaidya
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.
5 years, 10 months
