- Devel - oVirt List Archives

rounding microseconds in vm conf update
by Valentina Makarova 22 Jun '17

22 Jun '17

Hello! Ovirt sdk process updating of vm template with rounding of microseconds in creation_time. And vm is marked as vm which has a newer configuration because of this, but there is not a new configuration, all difference between current configuration and next_run configuration is creation_time. It is not correct. For example, diff between curl get-request for this state of vm and next_run state is: [ovirt-system-tests]$ diff current_state.txt next_state.txt 55c55 < <creation_time>2017-06-14T06:18:03*.987*-04:00</creation_time> --- > <creation_time>2017-06-14T06:18:03*.000*-04:00</creation_time> 76a77 And example how to request update for reach rounding is a test in ovirt_system_test: @ovirtlago.testlib.with_ovirt_api def update_round(api): vm = api.vms.get('vm0') #there vm.creation_time.isoformat() is a real datetime with microseconds vm.update() #after this vm.creation_time.isoformat() contains a real datetime with microseconds, #but vm becames vm with newer configuration and # next_run creation time becomes rounded to seconds Does anyone have idea how to fix this? Sincerely, Valentina Makarova

2 1

Re: [ovirt-devel] help with building a package with Copr
by Eyal Edri 22 Jun '17

22 Jun '17

Adding also devel list, I think there are some maintainers who build in copr. On Thu, Jun 22, 2017 at 6:23 AM, Marc Dequènes (Duck) <duck(a)redhat.com> wrote: > Quack, > > So my project is here: > https://copr.fedorainfracloud.org/coprs/duck/PostSRSd/build/568647/ > In the SCM URL I've got the spec file. > > I built this package on a CentOS 7.3 VM successfully and it currently > works well in production. > > On Copr I've got this error: > > https://copr-be.cloud.fedoraproject.org/results/ > duck/PostSRSd/epel-7-x86_64/00568647-postsrsd/build.log.gz > > So I made a small change (second commit) to try to make things simpler > just in case but it does not work better. > > So I'm at a loss. Could someone give a hand please? > \_o< > > > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > > -- Eyal edri ASSOCIATE MANAGER RHV DevOps EMEA VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

2 1

Lowering the bar for wiki contribution?
by Roy Golan 22 Jun '17

22 Jun '17

I'm getting the feeling I'm not alone in this, authoring and publishing a wiki page isn't as used to be for long time. I want to suggest a bit lighter workflow: 1. Everyone can merge their page - (it's a wiki) Same as with (public and open) code, no one has the motivation to publish a badly written wiki page under their name. True, it can have an impact, but not as with broken code 2. Use Page-Status marker The author first merges the draft. Its now out there and should be updated as time goes and its status is DRAFT. Maintainers will come later and after review would change the status to PUBLISH. That could be a header in on the page: --- page status: DRAFT/PUBLISH --- Simple I think, and should work.

14 23

dnf issue on FC24/25 slaves
by Gil Shinar 21 Jun '17

21 Jun '17

Today we have encountered a dnf issue on all of our FC24/25 slaves. It affected all Jenkins jobs that are running on these slaves. If you see this error message: *system-python: /builddir/build/BUILD/hawkey-0.6.3/src/sack.c:354: load_ext: Assertion `ret == 0' failed* please be patient. We are working to solve this issue in the next couple of minutes. It was basically a fedora mirror issue. They have a bug on it but looks like they have already fixed it. Thanks Gil

1 1

ovirt-node-ng-installer-master-2017062004 is missing the Updates repository.
by Mike Hulsman 20 Jun '17

20 Jun '17

------=_Part_53379_1338138929.1497963607312 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I installed the ovirt-node-ng-installer-master-2017062004.iso and tried to create a host from within a Ovirt-engine. I got the error: Failed to install Host node01. Yum Cannot queue package qemu-kvm-tools: Package qemu-kvm-tools cannot be found. The solution for this problem is to enable the updates in the /etc/yum.repos.d/CentOS-Base.repo file. I also see that the base repo is also disabled. Regards, Mike Hulsman Proxy Managed Services B.V. | www.proxy.nl | Enterprise IT-Infra, Open Source and Cloud Technology Delftweg 128 3043 NB Rotterdam The Netherlands | +31 10 307 0965 ------=_Part_53379_1338138929.1497963607312 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: Arial, Helvetica, sans-serif; font-s= ize: 12pt; color: #000000"><div>I installed the ovirt-node-ng-installer-mas= ter-2017062004.iso and tried to create a host from within a Ovirt-engine.<b= r></div><div>I got the error: Failed to install Host node01. Yum Cannot que= ue package qemu-kvm-tools: Package qemu-kvm-tools cannot be found.<br data-= mce-bogus=3D"1"></div><div><br data-mce-bogus=3D"1"></div><div>The solution= for this problem is to enable the updates in the /etc/yum.repos.d/CentOS-B= ase.repo file.<br data-mce-bogus=3D"1"></div><div><br data-mce-bogus=3D"1">= </div><div>I also see that the base repo is also disabled.<br data-mce-bogu= s=3D"1"></div><div><br data-mce-bogus=3D"1"></div><div><br></div><div data-= marker=3D"__SIG_PRE__">Regards, <br><br>Mike Hulsman<br><br>Proxy Managed S= ervices B.V. | www.proxy.nl | Enterprise IT-Infra, Open Source and Cloud Te= chnology<br>Delftweg 128 3043 NB Rotterdam The Netherlands | +31 10 307 096= 5</div></div></body></html> ------=_Part_53379_1338138929.1497963607312--

1 0

[ OST Failure Report ] [ oVirt master ] [ 19/06/17 ] [ add_secondary_storage_domains ]
by Gil Shinar 20 Jun '17

20 Jun '17

Test failed: 002_bootstrap.add_secondary_storage_domains Link to suspected patches: Link to Job: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/7264 Link to all logs: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/7264/artif… Error snippet from the log: Host 0: 2017-06-19 08:46:48,457-0400 WARN (jsonrpc/1) [storage.HSM] getPV failed for guid: 360014050f775dd654404bd39d061693c (hsm:1928) Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 1925, in _getDeviceList pv = lvm.getPV(guid) File "/usr/lib/python2.7/site-packages/vdsm/storage/lvm.py", line 852, in getPV raise se.InaccessiblePhysDev((pvName,)) InaccessiblePhysDev: Multipath cannot access physical device(s): "devices=(u'360014050f775dd654404bd39d061693c',)" 2017-06-19 08:46:48,546-0400 WARN (jsonrpc/1) [storage.LVM] lvm pvs failed: 5 [] [' Failed to find physical volume "/dev/mapper/360014050fae4a3a8e8047e6933531876".'] (lvm:322) 2017-06-19 08:46:48,546-0400 WARN (jsonrpc/1) [storage.HSM] getPV failed for guid: 360014050fae4a3a8e8047e6933531876 (hsm:1928) Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 1925, in _getDeviceList pv = lvm.getPV(guid) File "/usr/lib/python2.7/site-packages/vdsm/storage/lvm.py", line 852, in getPV raise se.InaccessiblePhysDev((pvName,)) InaccessiblePhysDev: Multipath cannot access physical device(s): "devices=(u'360014050fae4a3a8e8047e6933531876',)" Host 1: *2017-06-19 08:49:03,151-0400 ERROR (monitor/b92f872) [storage.Monitor] Setting up monitor for b92f8727-8c51-4e12-a3fe-5441531c13ca failed (monitor:329) Traceback (most recent call last): File "/usr/share/vdsm/storage/monitor.py", line 326, in _setupLoop self._setupMonitor() File "/usr/share/vdsm/storage/monitor.py", line 348, in _setupMonitor self._produceDomain() File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 237, in wrapper value = meth(self, *a, **kw) File "/usr/share/vdsm/storage/monitor.py", line 366, in _produceDomain self.domain = sdCache.produce(self.sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 108, in produce domain.getRealDomain() File "/usr/share/vdsm/storage/sdc.py", line 49, in getRealDomain return self._cache._realProduce(self._sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 132, in _realProduce domain = self._findDomain(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 149, in _findDomain return findMethod(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 174, in _findUnfetchedDomain raise se.StorageDomainDoesNotExist(sdUUID) StorageDomainDoesNotExist: Storage domain does not exist: (u'b92f8727-8c51-4e12-a3fe-5441531c13ca',)*

3 3

Heads up: VdcAction* classes names have been changed
by Tal Nisan 20 Jun '17

20 Jun '17

Hi all, I've merged patches to change the legacy name "VdcAction*" to "Action*", the Vdc prefix is here from long time ago and doesn't make much sense anymore (if it ever did). Please make sure you rebase your patches before submitting and make sure CI passes again even if it passed before rebasing. Changed classes are: VdcActionType -> ActionType VdcActionTypeDeserializer -> ActionTypeDeserializer VdcActionParametersBase -> ActionParametersBase VdcActionUtils -> ActionUtils Thanks for the reviewers that helped review those long and boring patches (amureini, masayah, frolland, ishaby, awels, gsheremeta, oourfali) Next up on my list is VdcQuery*, stay tuned :)

3 2

[ENGINE][ACTION_NEEDED] - default maintainers, per path
by Roy Golan 19 Jun '17

19 Jun '17

Hi all, Some time ago the infra team enabled *gerrit default reviewer plugin* which you probably noticed if you logged in to gerrit. What we can do is for example set the stable branch maintainers per branch automatically: [filter "branch:ovirt-engine-4.1"] reviewer = stableBranchMaintainersGroup Put people based on path: [filter "branch:master file:^frontend/.*"] reviewer = j.r.r.t(a)shire.me *Action Needed:* Nominate yourself, or others, by amending this patch online [1]. Once this patch is fully acked and agreed we will merge it. If something can't get consensus we will defer it from the patch till maintainers agree. [1] https://gerrit.ovirt.org/#/c/77488/

1 1

Heads up: Checkstyle is now enforcing blank lines between import groups in oVirt Engine
by Tal Nisan 18 Jun '17

18 Jun '17

A couple of years ago commit a4f50e3b introduced a new checkstyle validation in oVirt Engine that enforces the order of the imports since some of the developers did not use the standards from the Engine code format and this caused a situation where some commits included aside for the actual code also a reformat of the imports that was unrelated to the patch. After the validation was added the situation got better but there were still no 100% alignment since the Engine code format also defines that there should be that there should be a blank line between the different import groups and this was not enforced, a fact that caused some patches to add lines and some remove lines between the imports. Today I've merged commit bf298fed that fixes all the imports as per the project standard and commit 1c6b710 that adds a checkstyle validation that enforces this change so note that from now on you should maintain that. You can add the code format which is located in Engine root under config/engine-code-format.xml to your IDE to have the imports arranged automatically.

1 0

ovirt_master_hc-system-tests and gluster
by Sandro Bonazzola 18 Jun '17

18 Jun '17

Hi, I was looking at Bug 1429537 <https://bugzilla.redhat.com/show_bug.cgi?id=1429537> - [RFE] Rebase on gluster-3.10 for oVirt Hosted Engine and pretty happy that ovirt_master_hc-system-tests is green. But despite ovirt-release-master is enabling gluster 10 repositories[1], ovirt_master_hc-system-tests is consuming glusterfs 3.8.12[2] This jenkins job is therefore ineffective. Can you please fix the job for consuming glusterfs 3.10? Thanks, [1] https://gerrit.ovirt.org/#/c/74129/ [2] http://jenkins.ovirt.org/job/ovirt_master_hc-system-tests/133/artifact/expo… -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

3 2