- Devel - oVirt List Archives

[vdsm] new internal stable modules + proposal
by Francesco Romani 30 Mar '16

30 Mar '16

Hi, in the last Vdsm developer call we agreed to promote a few modules in the common repository. The common repository provides the additional guarantees over regular modules in lib/vdsm/ - stable API - (thus) safe to use across verticals the planned moves are: lib/vdsm/schedule.py -> lib/vdsm/common/schedule.py lib/vdsm/periodic.py -> lib/vdsm/common/periodic.py lib/vdsm/virt/api.py -> lib/vdsm/common/api.py Question is if those modules should go under common/ or under another subdirectory, maybe infra? Lastly, i have a proposal about better handling of those modules. First, the mere fact a module is placed under lib/vdsm/common provides the extra guarantees I mentioned. But should we added more annotations? for example something like __API__ = {} near the top of the module if this attribute exist, then the module is safe to use across verticals, has stable API and so forth (this is _in addition_ to the common/ package, not as replacement). Like: __API__ = { "introduced-in": "4.14.0", "deprecated-from": "4.18.0", "removed-at": "4.20.0", "contact": "fromani(a)redhat.com" } We could refine further this concept if we like it. The idea is to be lightweight as possible while carrying all the information we need. Comments welcome as usual bests, -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani

3 7

[ATN] [ACTION REQUIRED] Tweaking engine CI flow
by Roy Golan 30 Mar '16

30 Mar '16

Hi all, Eyal and I sat together to analyse and tweak the engine CI and this is what we came up with: - dao test excludes updated - exclude dal/src/main/bundles from invoking dao tests A trivial update of validation messages without any db change would trigger dao test without any need. This is one less job run for lots of patches. This change is effective now. - Spare CI re-run on trivial rebases Gerrit trigger supports suppressing itself if the change to the tree was trivial. Most of the waste of resources(time and IO :) ) is around rebasing a change and waiting for CI to rerun. if Change1 is ci+1 and Change2 is ci+1 the chances that they will break CI together is very small and taking that risk is most probably worth it due to the huge resources waste This change isn't effective yet - *Please reply here* if you agree or not to make this change available. All of this is 'master' - 3.6 will follow if we will agree on activating that change. Thanks, Roy

4 6

[VDSM] Vdsm build requires now python 3 on EL7
by Nir Soffer 30 Mar '16

30 Mar '16

Hi all, Since commit f247a0cff310 (el7: require newly available python34-nose), building vdsm requires Python 3 on EL7. Unfortunately, it seems that ovirt-release-master that should add all the dependencies needed for vdsm does is not configured properly, so building vdsm will fail. I heard that installing epel7 repo fixes this issue. Cheers, Nir [1] https://github.com/oVirt/vdsm/commit/f247a0cff310dbbf62b07e779adbe9973734a9…

6 6

Failing to run ovirt-system-tests using lago due to missing rpms
by Eyal Edri 29 Mar '16

29 Mar '16

Hi, Anyone encountered these errors when running 3.6 basic suite on RHEL 7.2? * STDERR Error: Package: ovirt-engine-3.6.4.1-1.el6.noarch (localsync) Requires: ovirt-iso-uploader >= 3.6.0 Error: Package: ovirt-engine-3.6.4.1-1.el6.noarch (localsync) Requires: slf4j >= 1.7.0 Available: slf4j-1.5.8-8.el6.noarch (base) slf4j = 1.5.8-8.el6 Error: Package: ovirt-engine-backend-3.6.4.1-1.el6.noarch (localsync) Requires: ovirt-host-deploy-java >= 1.4.0 Error: Package: ovirt-engine-vmconsole-proxy-helper-3.6.4.1-1.el6.noarch (localsync) Requires: ovirt-vmconsole-proxy Error: Package: ovirt-engine-3.6.4.1-1.el6.noarch (localsync) Requires: ovirt-image-uploader >= 3.6.0 Error: Package: ovirt-engine-backend-3.6.4.1-1.el6.noarch (localsync) Requires: ebay-cors-filter Error: Package: ovirt-engine-setup-base-3.6.4.1-1.el6.noarch (localsync) Requires: otopi >= 1.4.0 Error: Package: ovirt-engine-setup-plugin-ovirt-engine-3.6.4.1-1.el6.noarch (localsync) Requires: ovirt-engine-extension-aaa-jdbc Error: Package: ovirt-engine-3.6.4.1-1.el6.noarch (localsync) Requires: ovirt-engine-wildfly >= 8.2.1 Error: Package: ovirt-engine-setup-plugin-ovirt-engine-common-3.6.4.1-1.el6.noarch (localsync) Requires: ovirt-setup-lib Error: Package: ovirt-engine-backend-3.6.4.1-1.el6.noarch (localsync) Requires: vdsm-jsonrpc-java >= 1.1.8 Error: Package: ovirt-engine-backend-3.6.4.1-1.el6.noarch (localsync) Requires: ovirt-engine-extension-aaa-jdbc # [Thread-3] Deploy VM lago_basic_suite_3_6_engine: ERROR (in 0:01:59) Error while running thread Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/lago/utils.py", line 46, in _ret_via_queue queue.put({'return': func()}) File "/usr/lib/python2.7/site-packages/ovirtlago/__init__.py", line 472, in _deploy_host host.name(), RuntimeError: /home/eedri/lago/ovirt-system-tests/basic_suite_3.6/deploy-scripts/setup_engine.sh failed with status 1 on lago_basic_suite_3_6_engine @ Deploy oVirt environment: ERROR (in 0:01:59) Error occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 248, in do_run self.cli_plugins[args.ovirtverb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 180, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 174, in do_deploy prefix.deploy() File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 598, in wrapper func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/__init__.py", line 52, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/__init__.py", line 480, in deploy self._deploy_host, self.virt_env.get_vms().values() File "/usr/lib/python2.7/site-packages/lago/utils.py", line 88, in invoke_in_parallel vt.join_all() File "/usr/lib/python2.7/site-packages/lago/utils.py", line 46, in _ret_via_queue queue.put({'return': func()}) File "/usr/lib/python2.7/site-packages/ovirtlago/__init__.py", line 472, in _deploy_host host.name(), RuntimeError: /home/eedri/lago/ovirt-system-tests/basic_suite_3.6/deploy-scripts/setup_engine.sh failed with status 1 on lago_basic_suite_3_6_engine -- Eyal Edri Associate Manager RHEV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)

1 0

Engine 3.6.5 has been branched out
by Tal Nisan 29 Mar '16

29 Mar '16

A new branch ovirt-engine-3.6.5 has been branched out from the ovirt-engine-3.6 branch please note that: - 3.6.5 patches will now have to be backported to the new branch as well as the 3.6 branch - 3.6.6 patches should only be merged to the 3.6 branch only All 3.6.6 patches that were backported to the 3.6 and were pending the branching out can now be merged, please rebase and verify again.

2 1

Hello and a question about QEMU log
by zhukaijie 29 Mar '16

29 Mar '16

Hello, Each running VM has it's command line logged in /var/log/libvirt/qemu/${vmname}. And now I'd like to disable this log function, that is to say, not to record the QEMU command line of VM. Could you please tell me will can I configure it? Best wishes.

2 1

[ANN] oVirt 3.6.4 Final Release is now available
by Sandro Bonazzola 29 Mar '16

29 Mar '16

The oVirt Project is pleased to announce today the general availability of oVirt 3.6.4. This latest community release includes numerous bug fixes for - ovirt-engine - vdsm - ovirt-hosted-engine-setup - ovirt-hosted-engine-ha oVirt is an open-source, openly-governed enterprise virtualization management application, developed by a global community. You can use the oVirt management interface (oVirt Engine) to manage hardware nodes, storage and network resources, and to deploy and monitor virtual machines running in your data center. If you are familiar with VMware products, oVirt is conceptually similar to vSphere. oVirt serves as the bedrock for Red Hat's Enterprise Virtualization product, and it is the "upstream" project where new features are developed prior to their inclusion in Red Hat's supported product offering. Additional Resources: * Read more about the oVirt 3.6.4 release highlights: http://www.ovirt.org/release/3.6.4/ * 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/ -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

HEADS UP: otopi - enforce priority and other changes
by Yedidyah Bar David 29 Mar '16

29 Mar '16

Hi all, In two days or so, we are going to merge [1]. Without it, if you have events (functions with a '@plugin.event' decoration) that due to before=/after= requirements, otopi could not comply with their priority=, it will continue, ignoring this and only writing a message to the console if you set OTOPI_DEBUG=1. With this change, it will fail. Under normal circumstances, you'll see nothing in the console or the log, just an exit code of 1. If you set an environment variable OTOPI_DEBUG=1, it will emit a "RuntimeError: Priorities were reversed during buildSequence" error, see examples below. You can restore the existing behavior by setting another env var OTOPI_ALLOW_PRIORITY_OVERRIDE=1 . Soon thereafter, we are going to merge [2]. This will replace the algorithm that is used to decide what to run when. In principle, after [1] is merged, they should be compatible. However, the new algorithm does not allow overriding priorities. To revert to the old algorithm, you can set env var OTOPI_ALLOW_LEGACY_BUILDSEQ=1 . The old algorithm (and this option) is intended to be removed eventually, probably after oVirt 4.0 is released. Patches to make engine-setup (engine+dwh+reports) and host-deploy compatible with the new behavior were already merged to master branches. Still we most likely forgot some other tools/flows/etc., so if you encounter such failures please open a bug against the relevant tool. On a more positive (?) side, we also recently added a new package to master, called otopi-debug-plugins. It currently includes two plugins, which are not enabled by default. One of them allows you to get a prompt 'Press Enter to continue' on [ERROR], so it's easier to have a look at the system before the tool might try to rollback or something, the other allows you to enforce a failure at a certain stage, which might be useful to debug/verify failures and especially rollbacks. More details about these are in a new README file [3]. [1] https://gerrit.ovirt.org/55329 [2] https://gerrit.ovirt.org/28775 [3] https://gerrit.ovirt.org/gitweb?p=otopi.git;a=blob;f=README.debug-plugins Examples: 1. # ovirt-host-deploy # echo $? 1 2. # OTOPI_DEBUG=1 ovirt-host-deploy 2>&1 | tail Priorities were reversed during buildSequence: method <bound method ?._init of <otopi.plugins.otopi.core.log.Plugin object at 0x7f9827c9fe10>> with priority 2000 appears after method <bound method ?._preinit of <otopi.plugins.ovirt_host_deploy.core.misc.Plugin object at 0x1032990>> with priority 5000 Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/__main__.py", line 88, in main installer.execute() File "/usr/lib/python2.7/site-packages/otopi/main.py", line 151, in execute self.context.buildSequence() File "/usr/lib/python2.7/site-packages/otopi/context.py", line 400, in buildSequence raise RuntimeError(msg) RuntimeError: Priorities were reversed during buildSequence: method <bound method ?._init of <otopi.plugins.otopi.core.log.Plugin object at 0x7f9827c9fe10>> with priority 2000 appears after method <bound method ?._preinit of <otopi.plugins.ovirt_host_deploy.core.misc.Plugin object at 0x1032990>> with priority 5000 ('FATAL Internal error (main): Priorities were reversed during buildSequence: method <bound method ?._init of <otopi.plugins.otopi.core.log.Plugin object at 0x7f9827c9fe10>> with priority 2000 appears after method <bound method ?._preinit of <otopi.plugins.ovirt_host_deploy.core.misc.Plugin object at 0x1032990>> with priority 5000',) 3. # OTOPI_DEBUG=1 OTOPI_ALLOW_PRIORITY_OVERRIDE=1 ovirt-host-deploy ... Priorities were reversed during buildSequence: method <bound method ?._init of <otopi.plugins.otopi.core.log.Plugin object at 0x7fbe17f51e10>> with priority 2000 appears after method <bound method ?._preinit of <otopi.plugins.ovirt_host_deploy.core.misc.Plugin object at 0x107f8d0>> with priority 5000 [ INFO ] Stage: Initializing Continuing will configure this host for serving as hypervisor. Are you sure you want to continue? (yes/no) And with [2]: 4. # OTOPI_DEBUG=1 ovirt-host-deploy ... _toposortBuildSequence failed: Cyclic dependencies found ('FATAL Internal error (main): Cyclic dependencies found',) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/__main__.py", line 88, in main installer.execute() File "/usr/lib/python2.7/site-packages/otopi/main.py", line 151, in execute self.context.buildSequence() File "/usr/lib/python2.7/site-packages/otopi/context.py", line 665, in buildSequence self._sequence = self._toposortBuildSequence() File "/usr/lib/python2.7/site-packages/otopi/context.py", line 624, in _toposortBuildSequence raise RuntimeError(_('Cyclic dependencies found')) RuntimeError: Cyclic dependencies found 5. # OTOPI_DEBUG=1 OTOPI_ALLOW_PRIORITY_OVERRIDE=1 ovirt-host-deploy (fails the same way as (4.)) 6. # OTOPI_ALLOW_LEGACY_BUILDSEQ=1 OTOPI_DEBUG=1 ovirt-host-deploy (fails similarly to (2.) - you'll see more-or-less outputs of (4.) then (2.) combined) 7. # OTOPI_ALLOW_LEGACY_BUILDSEQ=1 OTOPI_DEBUG=1 OTOPI_ALLOW_PRIORITY_OVERRIDE=1 ovirt-host-deploy (succeeds like (3.), but with part of the output of (4.) before that) Best regards, -- Didi

1 0

Workaround for Gerrit 'Internal Server Error' after deleting draft
by Tomer Saban 28 Mar '16

28 Mar '16

Hi, I came across a bug in Gerrit when trying to delete a draft. It seems that it ruins the patchset(Gerrit doens't set the new last revision properly). So, in order to fix this issue we need to reset the last revision. In order, to do that you need to find the last revision after deleting the draft(Let's assume it's 23). Once, you have that you need to number of the patch in gerrit. For example, the number in: https://gerrit.ovirt.org/#/c/51636/ is 51636. Last, You need to run the following line from the shell: ssh gerrit.ovirt.org gerrit review --rebase 51636,23 FYI, Tomer

2 1

VDSM Network Tests
by Paul Maidment 27 Mar '16

27 Mar '16

I notice that on my build of VDSM, the network test. functional/networkTests.py:testDhcpReplaceNicWithBridge Fails on the assertion that the address will not change (the dnsmasq dhcp server returns a new address for the same mac) Can anyone reproduce this?

2 1