November 2018 - Devel - oVirt List Archives

[vdsm] illegible check-patch failure
by Dan Kenigsberg 18 Nov '18

18 Nov '18

This job https://jenkins.ovirt.org/job/vdsm_master_check-patch-fc28-x86_64/1965/cons… fails on 06:46:24 journal/b087148aba6d49b9bbef488e52a48752/system.journal 06:46:27 tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we read it (I think). Is that true? How can this be avoided?

2 1

[BACKUP] Estimating qcow2 disk image size before upload
by Nir Soffer 17 Nov '18

17 Nov '18

When uploading to qcow2 disks on block storage you must set the disk initial_size correctly so the system allocates big enough disk. If the initial size is too small, the upload will fail when trying to write after the end of the device. This info can be useful for people working on a backup solution for oVirt. The easiest case is upload of existing qcow2 image using the SDK. In this case we create a new disk with: initial_size=image_size, provisioned_size=virtual_size, image_size is the size of the file: os.stat('image').st_size Note that "qemu-img info" return "actual-size" - this is the allocated size on storage which is not helpful for uploading images. Example: https://github.com/oVirt/ovirt-engine-sdk/blob/78c3d5bd14eeb93ef72ec31d775f… A more tricky case is when a backup system keeps raw guest data, but know how to generate qcow2 image stream, without creating a temporary image. In this case the required size can be calculated by counting the number of clusters that need to be allocated in the final image. This depends on the location of the data in the image. For example this creates 1G image with only one cluster: $ python -c 'with open("one-cluster.raw", "wb") as f: f.truncate(1024**3) f.write("x")' $ ls -lhs one-cluster.raw 4.0K -rw-rw-r--. 1 nsoffer nsoffer 1.0G Nov 15 18:24 one-cluster.raw $ qemu-img measure -f raw -O qcow2 one-cluster.raw required size: 458752 fully allocated size: 1074135040 $ qemu-img convert -f raw -O qcow2 one-cluster.raw one-cluster.qcow2 $ ls -lhs one-cluster.qcow2 324K -rw-r--r--. 1 nsoffer nsoffer 384K Nov 15 18:25 one-cluster.qcow2 But this creates a fully allocated 1G image: $ python -c 'with open("fully-allocated.raw", "wb") as f: f.truncate(1024**3) for i in range(0, 1024**3, 64 * 1024): f.seek(i) f.write("x")' $ ls -lhs fully-allocated.raw 64M -rw-rw-r--. 1 nsoffer nsoffer 1.0G Nov 15 18:30 fully-allocated.raw $ qemu-img measure -f raw -O qcow2 fully-allocated.raw required size: 1074135040 fully allocated size: 1074135040 $ qemu-img convert -f raw -O qcow2 fully-allocated.raw fully-allocated.qcow2 $ ls -lhs fully-allocated.qcow2 1.1G -rw-r--r--. 1 nsoffer nsoffer 1.1G Nov 15 18:31 fully-allocated.qcow2 We had code in vdsm that does exactly this, and it was removed since qemu-img support a new "measure" command in RHEL 7.5 providing this info. But this works only for existing images. You can find the code in this vdsm commit: https://github.com/oVirt/vdsm/tree/4eee97d6aa532b6f3ecdfde0333d17c27c412f86 The module implementing estimation: https://github.com/oVirt/vdsm/blob/4eee97d6aa532b6f3ecdfde0333d17c27c412f86… The tests for this module: https://github.com/oVirt/vdsm/blob/4eee97d6aa532b6f3ecdfde0333d17c27c412f86… If you know the data ranges that will be written to the qcow2 image, you can count the clusters like this: https://github.com/oVirt/vdsm/blob/4eee97d6aa532b6f3ecdfde0333d17c27c412f86… Then you can use the cluster count to estimate qcow2 file size: https://github.com/oVirt/vdsm/blob/4eee97d6aa532b6f3ecdfde0333d17c27c412f86… Nir

2 3

[Ovirt] [CQ weekly status] [16-11-2018]
by Dafna Ron 16 Nov '18

16 Nov '18

Hi All, I want to just give a quick and simple status on CQ so that everyone is informed on the general state of our tests when they come in on beginning of the week. *Ovirt-Master*- *GREEN* *Ovirt-4.2* - *GREEN* Happy Week! Dafna

1 0

Setting Type and action Variables in Ovirt Validation messages
by Kaustav Majumder 16 Nov '18

16 Nov '18

Hi all, I am working on a bug where the error messages comes as non interpolated [ https://bugzilla.redhat.com/show_bug.cgi?id=1369319].I am trying to figure out where the 'type' and 'action' variables are set in ovirt for validation error messages One such example from AppErrors.properties is :- ACTION_TYPE_FAILED_GENERATOR_NOT_SUPPORTED_BY_CLUSTER=Cannot ${action} ${type}. The random number generator is not supported by the Cluster. Thanks, Kaustav

2 1

Re: [EXTERNAL] Re: List of Queries related to RHV
by Nir Soffer 15 Nov '18

15 Nov '18

On Wed, Oct 17, 2018 at 5:03 PM Mahesh Falmari <Mahesh.Falmari(a)veritas.com> wrote: > Thanks for the prompt response on these queries. We have few follow-up > queries mentioned inline. > > > > Thanks & Regards, > Mahesh Falmari > > > > *From:* Yaniv Lavi <ylavi(a)redhat.com> > *Sent:* Tuesday, October 16, 2018 7:19 PM > *To:* Mahesh Falmari <Mahesh.Falmari(a)veritas.com> > *Cc:* Nir Soffer <nsoffer(a)redhat.com>; Erez, Daniel <derez(a)redhat.com>; > Tal Nisan <tnisan(a)redhat.com>; Pavan Chavva <pchavva(a)redhat.com>; devel < > devel(a)ovirt.org>; James Olson <James.Olson(a)veritas.com>; Navin Tah < > Navin.Tah(a)veritas.com>; Sudhakar Paulzagade < > Sudhakar.Paulzagade(a)veritas.com>; Abhay Marode <Abhay.Marode(a)veritas.com>; > Suchitra Herwadkar <Suchitra.Herwadkar(a)veritas.com>; Nirmalya Sirkar < > Nirmalya.Sirkar(a)veritas.com>; Abhijeet Barve <Abhijeet.Barve(a)veritas.com> > *Subject:* [EXTERNAL] Re: List of Queries related to RHV > > > > > *YANIV LAVI* > > SENIOR TECHNICAL PRODUCT MANAGER > > Red Hat Israel Ltd. <https://www.redhat.com/> > > 34 Jerusalem Road, Building A, 1st floor > > Ra'anana, Israel 4350109 > > ylavi(a)redhat.com T: +972-9-7692306/8272306 F: +972-9-7692223 > IM: ylavi > > <https://red.ht/sig> > > *TRIED. TESTED. TRUSTED.* <https://redhat.com/trusted> > > @redhatnews <https://twitter.com/redhatnews> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> > > > > On Tue, Oct 16, 2018 at 4:35 PM Mahesh Falmari <Mahesh.Falmari(a)veritas.com> > wrote: > > Hi Nir, > > We have few queries with respect to RHV which we would like to understand > from you. > > > > *1. Does RHV maintains the virtual machine configuration file in back end?* > > Just like we have configuration files for other hypervisors like for > VMware it is .vmx and for Hyper-V, it is .vmcx which captures most of the > virtual machine configuration information in that. On the similar lines, > does RHV also maintains such file? If not, what is the other way to get all > the virtual machine configuration information from a single API? > > > > There is a OVF storage, but this is not meant for consumption. > Right, this is only for internal use. ... > *3. Do we have any version associated with the virtual machine?* > > Just like we have hardware version in case of VMware and virtual machine > version in case of Hyper-V, does RHV also associate any such version with > virtual machine? > > > > The HW version is based on the VM machine type. > > [Mahesh] Can you please elaborate more on this? How simply VM machine > type going to determine it’s version? > Arik, can you answer this? Regarding backup, I think you need to store the vm configuration at the time of the backup regardless of having a version or not. The amount of data is very small. > *4. Is it possible to create virtual machines with QCOW2 as base disks > instead of RAW?* > > We would like to understand if there are any use cases customers prefer > creating virtual machines from QCOW2 as base disks instead of RAW ones. > > > > That is a possibility in cases of thin disk on file storage. > > [Mahesh] Can you please elaborate more on this? > Using the UI you can use qcow2 format only for thin disks on block storage. Using the SDK you can also create qcow2 image on thin file based storage. You can see examples here: https://github.com/oVirt/ovirt-engine-sdk/blob/78c3d5bd14eeb93ef72ec31d775f… In 4.3 we plan to support qcow2 image format for both thin and preallocated disks to allow change block tracking for incremental backup. See html: https://github.com/oVirt/ovirt-site/blob/bc51f4a7867d9c7e3797da6da1d19e111c… > > > *5. RHV Deployment* > > What kind of deployments you have come across in the field? Does customers > scale their infrastructure by adding more datacenters/clusters/nodes or > they add more RHV managers? What scenarios trigger having more than one RHV > manager? > > > > We are all kind with oVirt. I depends on the use case. > I don't know about any stats from users, but the general idea is: - one engine - 1 or more DCs - 1 or more storage domains in a DC - 1 or more clusters per DCs - 1 or more hosts per cluster The theoretical limit is 2000 hosts per DC (limited by sanlock), but the practical limit is much lower. I don't think we have setups with more than 200 hosts. Martin, do you have more info on this? > *6. Image transfer* > > We are trying to download disk chunks using multiple threads to improve > performance of reading data from RHV. Downloading 2 disk chunks > simultaneously via threads should take approximately the same time. > > This is much more complicated to calculate. > But from our observations this takes roughly 1.5 times. > > It sounds like a reasonable speed up. Can RHVM server requests in parallel, > > Yes > if so are there any settings that need to be tweaked? > > We don't have any settings related to concurrency. > Here is an example: > Request 1 for chunk 1 from thread 1, Range: bytes=0-1023 > Request 2 for chunk 2 from thread 2, Range: bytes=1024-2047 > Takes roughly 1.5 seconds, whereas a single request would take 1 second. > Expecting it to take just around 1 second. > > 1.5 seconds for reading 1024 bytes? > [Mahesh] Seeking response to this query. > > The throughout you will get depends on many things: - are you communicating with the proxy (using proxy_url) or the daemon (transfer_url)? Accessing the daemon directly will be faster. - are you running on the same host as the daemon performing the transfer? - if you run on the same host, are you using unix socket? (15% improvement expected) - are you using the same connection per thread for entire transfer (huge improvement when doing small requests) - which version are you testing? we support keep alive connections only since 1.4.x. - are you using big enough requests? you will get best performance if you use one big request per thread - network bandwidth - storage speed For best throughput when downloading single disk, you should use multiple threads, each downloading one part of an image, but I'm not sure it worth the time to optimize this since backup are expected the run in the same time anyway, and you will quickly reach the storage limit while downloading disks for multiple vms on multiple hosts in the same time. I suggest testing the expected use case, not single download. > *7. Free and Thaw operation* > > For cinder based VM, API recommended for FS consistent backup. > > - POST /api/vms/<ID>/freezefilesystems > - POST /api/vms/<ID>/thawfilesystems > > Why do we need this whereas it is not required for other storage? > > Creating a snapshot does this for you in a case where you have the oVirt > guest agent install on the guest. > > [Mahesh] Thanks, we would also like to understand is there a way to > control crash/app consistent snapshots through REST APIs? > snapshots are always consistent if you have qemu guest agent installed, and the guest is using the guest agent scripts properly. Without the guest agent, or if it is not configured properly, file system will have to recover after restore, in the same way it recovers after power failure. To be able to resume a vm to the same state when the snapshot was done you need to include memory in the snapshot, but this make the snapshot much slower, depending on the amount of guest memory, and require huge amount of space, so I don't think it makes sense for backup. Regarding REST API, Arik can add more info about this. Nir

4 5

[CQ ovirt master] [ovirt-engine] - not passing for 10 days
by Ehud Yonasi 15 Nov '18

15 Nov '18

Hey, I've seen that CQ Master is not passing ovirt-engine for 10 days and fails on test suite called restore_vm0_networking here's a snap error regarding it: https://pastebin.com/7msEYqKT Link to a sample job with the error: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/11113/artifac… Can some1 have a look at it and help to resolve the issue?

8 29

Unassigned bugs for targeted releases
by Sandro Bonazzola 14 Nov '18

14 Nov '18

Hi, we have 32 bugs targeted to a release but without an assignee: https://bugzilla.redhat.com/buglist.cgi?quicksearch=classification%3Aovirt%… Can you please review the list and ensure someone will work on them or drop the target if they're not going to be worked on? Thanks -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

3 3

Proposing Shmuel Melamud as a Virt backend maintainer
by Michal Skrivanek 14 Nov '18

14 Nov '18

Hi all, I’d like to propose Shmuel as a backend maintainer for the virt area. He’s a good candidate with his 200+ patches and insight into complex parts of VM pools, templates, q35 support, v2v, sparsify... Feel free to bother him more with review requests;) Thanks, michal

7 6

Please Stop merging to ovirt-engine master branch
by Dafna Ron 14 Nov '18

14 Nov '18

Hi , Please stop merging to ovirt-engine master branch as we have been failing on different regressions for the last 11 days. I do not want any other regressions to be introduced until we can properly catch them which means we need to fix the current issues before merging more changes. Thanks, Dafna

3 4

vdsm has been tagged (v4.30.2)
by Milan Zamazal 14 Nov '18

14 Nov '18

1 0

VDSM-Gluster python 3 compatibility
by Kaustav Majumder 14 Nov '18

14 Nov '18

Hi all, I have been working on making vdsm-gluster python 3 compatible. I had some queries regarding the tool used for getting storage devices info. Till now vdsm uses python blivet for getting the device tree information. I am not sure if blivet is compatible with python 3 so I had two propositions which I want some advice on. 1) Using lsblk and parsing the output 2) Using ansible modules locally in the vdsm hosts. Although I feel the 2nd way will add more dependencies to the project but it can help us in the long run to add more functionality easily. Thanks, Kaustav

2 2

Re: [CentOS-devel] SIGs: Possibility to drop EOL content at 7.6.1810 release time
by Sandro Bonazzola 13 Nov '18

13 Nov '18

Il giorno ven 2 nov 2018 alle ore 12:33 Niels de Vos <ndevos(a)redhat.com> ha scritto: > On Thu, Nov 01, 2018 at 11:01:51AM +0200, Anssi Johansson wrote: > ... > > For reference and inspiration, here are some directories from > > mirror.centos.org, including both up-to-date content and potentially EOL > > content. SIGs should review the list to make sure these directories can > > be copied over to 7.6.1810 when that time comes. Making the decisions > > now would save a bit of time at 7.6.1810 release time. > > > .. > > > storage/x86_64/gluster-3.10 > > storage/x86_64/gluster-3.12 > > The above two can be dropped (also for CentOS 6). This includes the > centos-release-gluster310 and centos-release-gluster-312 packages in > Extras. > > Can we keep 3.12? It's still consumed by oVirt 4.2. Adding oVirt devel team, just in case we'll need urgently to rebase on newer Gluster on CentOS 7.6 GA or block upgrade to CentOS 7.6 from oVirt side till we figure out how to handle. > > storage/x86_64/gluster-4.0 > > storage/x86_64/gluster-4.1 > > storage/x86_64/gluster-5 > > These three are still maintained. > > Thanks, > Niels > _______________________________________________ > CentOS-devel mailing list > CentOS-devel(a)centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

3 6

Upstream package missing release suffix
by Ales Musil 13 Nov '18

13 Nov '18

Hello, ovirt-lldp-labeler is missing release suffix in nightly build [1]. This has been fixed some time ago in [2]. Any idea what could be wrong? Thank you. Regards, Ales. [1] https://plain.resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ [2] https://gerrit.ovirt.org/c/94616/ -- 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

[VDSM] Proposing Denis as vdsm gluster maintainer
by Nir Soffer 13 Nov '18

13 Nov '18

Hi all, Denis is practically maintaining vdsm gluster code in the recent years, and it is time to make this official. Please ack, Nir

7 6

ovirt-engine has been tagged (ovirt-engine-4.2.7.5 )
by Tal Nisan 12 Nov '18

12 Nov '18

1 0

[ACTION REQUIRED] oVirt 4.3.0 Beta preparations
by Sandro Bonazzola 12 Nov '18

12 Nov '18

Hi, we'd like to be ready for releasing a first oVirt 4.3.0 beta on November 26th. In order to do that, we need all packages to be ready for it by Sunday November 25th. Maintainers: please ensure your packages can be installed are feature complete with regards to ovirt-4.3.0 target and passed CI testing. An integration testing on the master nightly will be done manually on Friday November 23rd to ensure basic functionalities are working as expected. Please note we don't have any guarantee that CentOS 7.6 will be out by that time. Please check oVirt 4.3 Beta release criteria[1] and help getting ready for it. If you have something that should block the beta release please raise the issue as soon as possible. Thanks, [1] https://www.ovirt.org/develop/release-management/releases/4.3/release-manag… -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

3 4

amount of reports by abrt
by Piotr Kliczewski 11 Nov '18

11 Nov '18

I attended a talk about abrt and noticed there are good number of reports [1] generated by issues in ovirt. Thanks, Piotr [1] https://retrace.fedoraproject.org/faf/reports/

3 4

ovirt-engine external IDP (Keycloak) integration
by Ravi Shankar Nori 08 Nov '18

08 Nov '18

Hi All, Please find design document [1] for integrating ovirt-engine with Keycloak using mod_auth_openidc. Engine can be configured to use external IDP to handle user authentication while still supporting Rest API bearer authentication. There are some changes to how clients will obtain tokens to use for bearer authentication. All clients need to request tokens from the external IDP and use it to access engine. When external authentication is enabled admin@internal and all internal profiles for authentication are disabled. Please see the design document for more details. Thanks Ravi [1] https://docs.google.com/document/d/1Wio7bQNeNinx7Luj5t-KpsSYQ2Z1Y0I8UhUyJAZ… Integration Issues that need attention 1. Ovirt-engine Python, Java and Ruby SDKs need to be modified to obtain token from either engine SSO or external OpenID Connect IDP. 2. OVN if we are not using SDK needs to be modified to obtain token from either engine SSO or external OpenID Connect IDP. 3. OVN changes needed to config user admin@internal. admin@internal access will be disabled if external integration is enabled. So OVN needs to be configurable to use another user for REST API access. 4. Ansible is using SDK, if SDK is fixed to use a file the file needs to passed from ansible to SDK. 5. Cloudforms and Satellite are using Ruby SDK, we need to file a bug to fix the issue. The file with the details of external IDP URL and client-id and client-secret needs to be passed to SDK. 6. REST API SDK V3 is not going to work with password and negotiate authentication 7. VM Single Sign-on will not work as we don’t have a password. 8. VM Console needs to work, if VM console is using token and bearer authentication everything should work

3 3

Failing compilation of engine to RPM using build-artefacts.sh
by Andrej Krejcir 08 Nov '18

08 Nov '18

Hi, I use a VM with latest CentOS to compile engine to RPM. Steps: - git clone repo from my dev machine to the VM - run ovirt-engine/automation/build-artifacts.sh This used to work, but since about 2 weeks ago the build fails with an error message: + %py_byte_compile /usr/bin/python2 /root/rpmbuild/BUILDROOT/ovirt-engine-4.3.0-0.0.master.20181105130924.git58423b7.el7.x86_64/usr/share/ovirt-engine/ /var/tmp/rpm-tmp.f7B35C: line 82: fg: no job control error: Bad exit status from /var/tmp/rpm-tmp.f7B35C (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.f7B35C (%install) Attaching the whole build log and the file '/var/tmp/rpm-tmp.f7B35C'. I'm not sure how to fix this. Can anyone help? Thanks, Andrej

2 1

Fwd: [oVirt Jenkins] ovirt-system-tests_network-suite-4.2 - Build # 719 - Still Failing!
by Eitan Raviv 07 Nov '18

07 Nov '18

Hi, We have a failure on OST/network-suite-master for several days now. My suspicions of the cause are detailed below. Can you have a look? Thanks ---------- Forwarded message --------- From: Eitan Raviv <eraviv(a)redhat.com> Date: Mon, Nov 5, 2018 at 8:39 AM Subject: Re: [oVirt Jenkins] ovirt-system-tests_network-suite-4.2 - Build # 719 - Still Failing! To: Ori Liel <oliel(a)redhat.com> Hi, Can you have a look? Thanks On Thu, Nov 1, 2018 at 10:08 AM Eitan Raviv <eraviv(a)redhat.com> wrote: > Hi Ondra, > > We have above failure on OST network-suite-4.2 [1] due to: > Fault reason is "Request syntactically incorrect.". Fault detail is "For > correct usage, see: > https://192.168.201.4/ovirt-engine/apidoc#services/vm/methods/preview_snaps… > " > > and I see in engine.log [2]: > > javax.xml.bind.UnmarshalException: unexpected element (uri:"", local:"disks") > > at the same time I see in model_4.2 [3] that a change was done to add the disks, but if i am not mistaken the ovirt-engine-sdk pom.xml [4] was not bumped to reflect this change. > > Can you please check? > > Thanks > > [1] > https://jenkins.ovirt.org/job/ovirt-system-tests_network-suite-4.2/719/arti… > [2] > https://jenkins.ovirt.org/job/ovirt-system-tests_network-suite-4.2/717/arti… > [3] > https://gerrit.ovirt.org/#/q/project:ovirt-engine-api-model+branch:model_4.2 > [4] https://gerrit.ovirt.org/#/q/project:ovirt-engine-sdk+branch:sdk_4.2 > > > > ---------- Forwarded message --------- > From: Edward Haas <edwardh(a)redhat.com> > Date: Thu, Nov 1, 2018 at 8:35 AM > Subject: Fwd: [oVirt Jenkins] ovirt-system-tests_network-suite-4.2 - Build > # 719 - Still Failing! > To: <rhevm-network-staff(a)redhat.com> > > > FYI > > ---------- Forwarded message --------- > From: <jenkins(a)jenkins.phx.ovirt.org> > Date: Thu, Nov 1, 2018 at 6:02 AM > Subject: [oVirt Jenkins] ovirt-system-tests_network-suite-4.2 - Build # > 719 - Still Failing! > To: <lgoldber(a)redhat.com>, <edwardh(a)redhat.com>, <infra(a)ovirt.org> > > > Project: > http://jenkins.ovirt.org/job/ovirt-system-tests_network-suite-4.2/ > Build: > http://jenkins.ovirt.org/job/ovirt-system-tests_network-suite-4.2/719/ > Build Number: 719 > Build Status: Still Failing > Triggered By: Started by timer > > ------------------------------------- > Changes Since Last Success: > ------------------------------------- > Changes for Build #717 > [Marcin Sobczyk] Change logging level for 'schema.inconsistency' > > > Changes for Build #718 > [Ales Musil] master: Update master suite compatibility version > > > Changes for Build #719 > [Ales Musil] master: Update master suite compatibility version > > > > > ----------------- > Failed Tests: > ----------------- > 1 tests failed. > FAILED: > network-suite-4.2.tests.test_mac_pools.test_undo_preview_snapshot_when_mac_used_reassigns_a_new_mac > > Error Message: > Error: Fault reason is "Request syntactically incorrect.". Fault detail is > "For correct usage, see: > https://192.168.201.4/ovirt-engine/apidoc#services/vm/methods/preview_snaps…". > HTTP response code is 400. > > Stack Trace: > system = <lib.system.SDKSystemRoot object at 0x7fc7f91f48d0> > default_cluster = <lib.clusterlib.Cluster object at 0x7fc7f91f4bd0> > ovirtmgmt_vnic_profile = <lib.netlib.VnicProfile object at 0x7fc7f81b3710> > cirros_template = 'Cirros_0_4_0' > > def test_undo_preview_snapshot_when_mac_used_reassigns_a_new_mac( > system, default_cluster, ovirtmgmt_vnic_profile, > cirros_template): > with virtlib.vm_pool(system, size=2) as (vm_0, vm_1): > vm_0.create(vm_name=VM0, > cluster=default_cluster, > template=cirros_template) > vm_0.wait_for_down_status() > > vm_0.run() > vm_0.wait_for_up_status() > > nicless_snapshot = _create_snapshot(vm_0) > > vm_0.create_vnic(NIC_NAME_1, ovirtmgmt_vnic_profile, > MAC_ADDR_1) > vm_0.stop() > vm_0.wait_for_down_status() > > > nicless_snapshot.preview() > > network-suite-4.2/tests/test_mac_pools.py:124: > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ > network-suite-4.2/lib/virtlib.py:243: in preview > snapshot=self.get_sdk_type() > /usr/lib64/python2.7/site-packages/ovirtsdk4/services.py:31091: in > preview_snapshot > return self._internal_action(action, 'previewsnapshot', None, headers, > query, wait) > /usr/lib64/python2.7/site-packages/ovirtsdk4/service.py:299: in > _internal_action > return future.wait() if wait else future > /usr/lib64/python2.7/site-packages/ovirtsdk4/service.py:55: in wait > return self._code(response) > /usr/lib64/python2.7/site-packages/ovirtsdk4/service.py:296: in callback > self._check_fault(response) > /usr/lib64/python2.7/site-packages/ovirtsdk4/service.py:132: in > _check_fault > self._raise_error(response, body) > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > _ _ _ > > response = <ovirtsdk4.http.Response object at 0x7fc7f81b3350> > detail = <ovirtsdk4.types.Fault object at 0x7fc7f81b39d0> > > @staticmethod > def _raise_error(response, detail=None): > """ > Creates and raises an error containing the details of the > given HTTP > response and fault. > > This method is intended for internal use by other components > of the > SDK. Refrain from using it directly, as backwards > compatibility isn't > guaranteed. > """ > fault = detail if isinstance(detail, types.Fault) else None > > msg = '' > if fault: > if fault.reason: > if msg: > msg += ' ' > msg = msg + 'Fault reason is "%s".' % fault.reason > if fault.detail: > if msg: > msg += ' ' > msg = msg + 'Fault detail is "%s".' % fault.detail > if response: > if response.code: > if msg: > msg += ' ' > msg = msg + 'HTTP response code is %s.' % response.code > if response.message: > if msg: > msg += ' ' > msg = msg + 'HTTP response message is "%s".' % > response.message > > if isinstance(detail, six.string_types): > if msg: > msg += ' ' > msg = msg + detail + '.' > > class_ = Error > if response is not None: > if response.code in [401, 403]: > class_ = AuthError > elif response.code == 404: > class_ = NotFoundError > > error = class_(msg) > error.code = response.code if response else None > error.fault = fault > > raise error > E Error: Fault reason is "Request syntactically incorrect.". Fault > detail is "For correct usage, see: > https://192.168.201.4/ovirt-engine/apidoc#services/vm/methods/preview_snaps…". > HTTP response code is 400. > > /usr/lib64/python2.7/site-packages/ovirtsdk4/service.py:118: Error >

4 7

[ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 05-11-2018 ] [ 002_bootstrap.add_dc ]
by Dafna Ron 06 Nov '18

06 Nov '18

Hi, We failed to add a DC due to computability level in the upgrade suite. The upgrade suite is upgrading 4.2 to master. Eli, can you please check if any fix is needed for upgrade? Link and headline of suspected patches: https://gerrit.ovirt.org/#/c/95190/ - engine: Remove Cluster Levels 3.6 and 4.0 Link to Job: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/10975 Link to all logs: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/10975/artifa… (Relevant) error snippet from the log: <error> 2018-11-04 06:26:54,619-05 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [1d8362d9] EVENT_ID: USER_VDC_LOGIN(30), User admin@internal-authz connecting from '192.168.201.1' using session 'v2y73+8hVB7ccwgjlAQOAK539eW6UsAysQQHbbiSy+mGDSTjOyZ38bpl9XLrGXSLJAqKyeXSdqfrbAqB4qWZUA==' logged in. 2018-11-04 06:26:54,873-05 WARN [org.ovirt.engine.core.bll.storage.pool.AddEmptyStoragePoolCommand] (default task-1) [4b627395-5dd6-4211-a63e-d78f3728ec6f] Validation of action 'AddEmptyStoragePool' failed for user admin@internal-authz. Reasons: VAR__TYPE__STORAGE__POOL,VAR__ACTION__CREATE,ACTION_TYPE_FAILED_GIVEN_VERSION_NOT_SUPPORTED 2018-11-04 06:26:54,877-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-1) [] Operation Failed: [Cannot create Data Center. Selected Compatibility Version is not supported. </error>

2 2

Fwd: [CentOS-devel] Point-release Freeze is Active
by Sandro Bonazzola 02 Nov '18

02 Nov '18

FYI. This shouldn't affect directly oVirt 4.2.7 but further updates to oVIrt deps will need to wait till CentOS 7.6 will be out. ---------- Forwarded message --------- From: Brian Stinson <brian(a)bstinson.com> Date: gio 1 nov 2018 alle ore 16:29 Subject: [CentOS-devel] Point-release Freeze is Active To: <centos-devel(a)centos.org> Hi Folks, As is usual, we freeze the SIG Sign + Push process as part of preparing for a point release. This helps us once CR is ready (it isn't yet, though) so that we can seed it quickly in CBS to build against. The Point-release Freeze does not affect content moving from the testing tags in CBS to buildlogs.c.o, that will continue to show up as it is built. Do note: since we do want to give testers and developers an opportunity to build and test against an upcoming point-release before it goes GA, content coming from buildlogs.centos.org may require enabling the CR repo once it's ready. Any new requests for sign+push (adding new tags to mirror.c.o) during Point-release Freeze will be held until the point release goes GA. If there are any questions, please let us know and discuss here on the list. Cheers! -- Brian Stinson _______________________________________________ CentOS-devel mailing list CentOS-devel(a)centos.org https://lists.centos.org/mailman/listinfo/centos-devel -- 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

Fwd: Fedora 30 System-Wide Change: Deprecating /etc/sysconfig/nfs
by Sandro Bonazzola 01 Nov '18

01 Nov '18

FYI ---------- Forwarded message --------- From: Ben Cotton <bcotton(a)redhat.com> Date: mer 17 ott 2018 alle ore 15:29 Subject: Fedora 30 System-Wide Change: Deprecating /etc/sysconfig/nfs To: <devel(a)lists.fedoraproject.org>, <devel-announce(a)lists.fedoraproject.org > https://fedoraproject.org/wiki/Changes/nfs.conf == Summary == Deprecate /etc/sysconfig/nfs and only use /etc/nfs.conf to configure NFS daemons. == Owner == * Name: Steve Dickson * Email: steved(a)redhat.com == Detailed Description == Since the beginning /etc/sysconfig/nfs has been used to configure the NFS server daemons by supply command line arguments to the daemons or commands via SysVinit scripts. Then systemd(1) came along and the idea of daemons self-configuration was started. Meaning daemons and commands would get their configurations from a file, not the command line like with SysVinit scripts. Back in late 2016, Neil Brown from SuSe, implemented this changed. He built into each daemon the ability to read from one central file, /etc/nfs.conf. See nfs.conf(5) for details. After this work made it upstream, I a wrote patch that added back the ability to use /etc/sysconfig/nfs to maintain backwards compatibility which has lasted for the last few Fedora releases. I think at this point, the timing is right to introduce this single file configuration to Fedora 30. == Benefit to Fedora == * Having a single file configuration will help IT automation systems like Ansible configure NFS servers. * This change also simplifies the systemd scrips. * Having two ways of configuring NFS is not desirable. The only reason there has been no problems is because nobody know about /etc/nfs.conf * There is a new command, nfsconf(8), that checks the correctness of /etc/nfs.conf == Scope == * Proposal owners: Steve Dickson <steved(a)redhat.com> * Other developers: Justin Mitchell <jumitche(a)redhat.com> * Release engineering: [https://pagure.io/releng/issue/7864 #7864 F30: Deprecating /etc/sysconfig/nfs] ** List of deliverables: nfs-utils-2.3.3-1.fc30 * Policies and guidelines: The guidelines to use /etc/nfs.conf are already being install with nfs.conf(5) and nfsconf(8) manpages * Trademark approval: No trademarks are being changed so no approval is needed. == Upgrade/compatibility impact == In [https://bugzilla.redhat.com/show_bug.cgi?id=1619270 BZ1619270] a python script that will convert a sysconfig/nfs config into nfs.conf config. There are a couple thoughts on how to use it. On clean installs, when sysconfig/nfs does not exist, sysconfig/nfs wil still be installed with directions to use nfs.conf to do the configuration. When sysconfig/nfs does exist, the configuration will '''not''' be overwritten, but the systemd scripts will not use the file to configure NFS. The two thoughts on how to use python script: # Have the upgrade run the script and maybe throw out a message that the configuration has now been moved to nfs.conf # Throw a message indicating the NFS configuration has changed and then have the admin run the script The first thought is probably the cleanest but changing configurations behind admin's back is not very nice... I am very open on how to use this script. == How To Test == With the new nfsconf(8) command, the nfs.conf can be tested for correctness, other than that, we should do the same testing as we do today == User Experience == After the initial shock, I think users will embrace the new configuration. Being able to configure NFS via IT automation systems (aka Ansible) is a step in the right direction. Having a command to check the correctness of the configuration will be welcome. == Dependencies == There are no dependencies that I know of. == Contingency Plan == * Contingency mechanism: Revert the commit that removed support for /etc/sysconfig/nfs. * Contingency deadline: 2019-03-05 (Beta Freeze) * Blocks release? No * Blocks product? No == Documentation == There are two man pages, nfs.conf(5) and nfsconf(8). == Release Notes == The new way of configuring NFS should be release noted. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://www.redhat.com/en/events/red-hat-open-source-day-italia?sc_cid=701f…>

2 1