December 2016 - lago-devel - oVirt List Archives

Lago v0.30 released
by Nadav Goldin 26 Dec '16

26 Dec '16

Hi, New Lago version is out - v0.30, this release adds few major improvements: 1. Fedora 25 RPMs are now available, also dropping support for Fedora 23 after it was EOL'ed last week(last fc23 version is 0.29). 2. 'lago collect' command now uses SCP to extract files, if SSH in the VM is unavailable it will attempt to use libguestfs. 3. List multiple IPs in each VM. 4. ovirtlago: add new test_equals* assertion functions to the testlib. Other than that this release includes quite a few bug fixes, details are in the change-log below. Thanks for everyone who contributed and reported issues. To upgrade using yum or dnf simply run: yum/dnf update lago Note to ovirt-system-tests users: you might need to re-enable the 'ovirtlago' service after upgrading, this can be done by running: sudo firewall-cmd --add-service=ovirtlago --permanent sudo firewall-cmd --reload If you find any problems, please open an issue in the GitHub page[1]. Docs: http://lago.readthedocs.io/en/0.30/ RPM Repository: http://resources.ovirt.org/repos/lago/stable/0.0/rpm/ GitHub: https://github.com/lago-project/lago/ For OST docs: http://ovirt-system-tests.readthedocs.io/en/latest/ The full change-log: * Mon Dec 26 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.30.0 bfd635d8: Merge pull request #400 from mykaul/multiple_ips 1dc030f5: Add a function to get all the IPs of a VM * Mon Dec 26 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.29.10 d62571fa: Merge pull request #385 from leongold/master 39babc10: added test_equals* tests in order for testlib to include tests * Mon Dec 26 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.29.9 b79fc534: Merge pull request #404 from mykaul/master 8855d669: Fix IPv6 subnet allocation. * Mon Dec 26 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.29.8 ca83aab0: Merge pull request #406 from nvgoldin/sshinject ac4f2df0: Revert usage of 'ssh-inject' in sysprep * Mon Dec 26 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.29.7 d94b452f: Merge pull request #383 from nvgoldin/guestfs_backend 4f6eb28d: use LIBGUESTFS_BACKEND variable if set * Mon Dec 26 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.29.6 71b93315: Merge pull request #382 from nvgoldin/continue_on_failure 0f8cee80: ovirtlago: drop exception handling in test_sequence_gen * Sun Dec 25 2016 Yaniv Kaul <ykaul(a)redhat.com> - 0.29.5 c58abf06: Merge pull request #395 from mykaul/inject-keys 9f9e7185: Small sysprep fixes * Sun Dec 25 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.29.4 60bde7d9: Merge pull request #388 from nvgoldin/extract_scp f7c5762a: Refactor collect command to use SCP * Sun Dec 25 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.29.3 62c92b12: Merge pull request #405 from nvgoldin/wait_net 511e3dc5: Check network is active after creation * Mon Dec 19 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.29.2 f4b86af2: Merge pull request #396 from mykaul/fix_apiv4 ed77c957: Fix oVirt APIv4 creation * Mon Dec 19 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.29.1 12b7fbbf: Merge pull request #391 from nvgoldin/guestfs_params afec1ac3: automation: configure KVM and libguestfs parameters Enjoy! Nadav. [1] http://github.com/lago-project/lago/issues

1 0

Re: [lago-devel] [Infra-private] Jenkins failure - parallel build?
by Barak Korren 25 Dec '16

25 Dec '16

On 20 December 2016 at 14:31, Yaniv Kaul <ykaul(a)redhat.com> wrote: > > > On Tue, Dec 20, 2016 at 12:32 PM, Barak Korren <bkorren(a)redhat.com> wrote: >> >> Its just its "nice" way of telling you that check_merged failed on fc23: >> http://jenkins.ovirt.org/job/lago_master_check-merged-fc23-x86_64/276/ > > > Thanks. That seem to fail on an unrelated issue to my patch... > > 08:21:16 not ok 16 basic.full_run: shell to a vm > 08:21:16 # (from function `helpers.contains' in file > tests/functional/helpers.bash, line 96, > 08:21:16 # in test file tests/functional/basic.bats, line 201) > 08:21:16 # `helpers.contains "$output" "$expected_hostname"' failed > > 08:21:16 # RUNNING:lago shell lago_functional_tests_vm01 hostname > > > ARGH... I'll look into it. > Y. > Worked fine on fc24 and el7, so maybe just drop fc23? Adding Nadav and Gal, moving to lago-devel. -- Barak Korren bkorren(a)redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/

3 3

[Attention] Lago release on Tuesday - 20.12.2016
by Nadav Goldin 25 Dec '16

25 Dec '16

Hey all, We plan to release Lago 0.30 on Tuesday, so please make sure all PRs are merged until 11:00 - 20.12.2016 TLV time. Thanks, Nadav.

1 2

New Lago release - v0.29
by Nadav Goldin 13 Dec '16

13 Dec '16

Hey all, New Lago version is out - 0.29, this is a small release with few bug fixes and enhancements, namely: 1. Improvement to VM boot time - interactive boot-menu will now be disabled for fc24/el7 images. 2. The SCSI controller will be generated only if virtio-SCSI is used. 3. 'lago ovirt reposetup' command will run per repository and will handle better conflicting RPMs stored in the local cache. 4. Two bug fixes in the ovirtlago testing library. To upgrade using yum or dnf simply run: yum/dnf update lago If you find any problems, please open an issue in the GitHub page[1]. Known issue with ovirt-system-tests ----------------------------------------------------- After upgrading, the 'ovirtlago' service might be disabled which will fail the 'reposetup' stage. As a work-around please run: sudo firewall-cmd --add-service=ovirtlago --permanent sudo firewall-cmd --reload If not using firewalld, see [2] for iptables instructions. This is caused due to a bug in the spec file, apologizes for the inconvenience. Docs: http://lago.readthedocs.io/en/0.29/ RPM Repository: http://resources.ovirt.org/repos/lago/stable/0.0/rpm/ GitHub: https://github.com/lago-project/lago/i For OST docs: http://ovirt-system-tests.readthedocs.io/en/latest/ The full change-log: * Sun Dec 11 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.29.0 3cf8d87c: Merge pull request #377 from nvgoldin/log_skiptest 916cd379: ovirtlago: log skipped tests to stdout * Sun Dec 11 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.28.5 45a445b7: Merge pull request #376 from mykaul/sysprep_edit b2511c45: Reduce boot time * Sun Dec 11 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.28.4 955974de: Merge pull request #372 from nvgoldin/caps_bug 53262943: ovirtlago: fix bug in capabilities * Wed Dec 07 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.28.3 fbb96183: Merge pull request #374 from mykaul/fix_reposetup 1e935e94: Fix reposync - use 'continue', not 'return' * Tue Dec 06 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.28.2 48bffab0: Merge pull request #369 from nvgoldin/bz1399235 e8a6edb7: make reposync more verbose and fix bz 1399235 * Mon Dec 05 2016 Lago CI bot <dcaroest+cibot(a)redhat.com> - 0.28.1 e8d11e3d: Merge pull request #370 from mykaul/scsi_on_demand ef337fff: Create the SCSI controller only if needed. Enjoy! Nadav. [1] http://github.com/lago-project/lago/issues [2] https://github.com/lago-project/lago/pull/379/commits/454930fab2bb7477cedc4…

1 0

New error in mock on lago check_patch
by Nadav Goldin 12 Dec '16

12 Dec '16

Hi Barak, I saw a new error[1] in mock today, IIRC this is not the same error as the usual 'mirror unavailable': DEBUG util.py:502: Executing command: ['/usr/bin/yum-deprecated', '--installroot', '/var/lib/mock/fedora-24-x86_64-b43344fe05507be58adc19b93da78705-5023/root/', '--releasever', '24', 'install', '@buildsys-build', 'bats', 'git', 'python-dulwich', 'python2-devel', 'python-virtualenv', 'python-libguestfs', 'libxslt-devel', 'libvirt-devel', 'libffi-devel', 'openssl-devel', 'dnf-command(builddep)', 'grubby', 'python-pip', '--setopt=tsflags=nocontexts'] with env {'PS1': '<mock-chroot> \\s-\\v\\$ ', 'SHELL': '/bin/bash', 'TERM': 'vt100', 'LC_MESSAGES': 'C', 'HOME': '/builddir', 'LD_PRELOAD': '/tmp/tmpzv6o4sbn/$LIB/nosync.so', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'en_US.UTF-8'} and shell False DEBUG util.py:421: Yum command has been deprecated, use dnf instead. DEBUG util.py:421: See 'man dnf' and 'man yum2dnf' for more information. DEBUG util.py:421: http://mirror.math.princeton.edu/pub/fedora/linux/updates/24/x86_64/repodat…: [Errno -1] repomd.xml does not match metalink for updates DEBUG util.py:421: Trying other mirror. DEBUG util.py:421: http://repo.atlantic.net/fedora/linux/updates/24/x86_64/repodata/repomd.xml: [Errno -1] repomd.xml does not match metalink for updates DEBUG util.py:421: Trying other mirror. DEBUG util.py:421: https://mirrors.kernel.org/fedora/updates/24/x86_64/repodata/repomd.xml: .... You think it might be related to the cache change? Thanks, Nadav. [1] http://jenkins.ovirt.org/job/lago_master_check-patch-fc24-x86_64/260/artifa…

3 7

Fwd: Lago/o-s-t VLAN/dnsmasq issue.
by Leon Goldberg 07 Dec '16

07 Dec '16

Hey, I suspect there's an issue where the current configuration of o-s-t (I've only tried basic-suite-4.0, but I guess it is not suite related), and more specifically dnsmasq's dhcp configuration under Lago/o-s-t (or otherwise) fails to serve VLAN interfaces. After successfully running basic-suite-4.0, I'm trying to call dhclient to serve eth0.600 on host0 (created in 005_network_by_label), which fails. DHCPDISCOVER(s) are reaching the bridge dnsmasq listen on, however no offers are being sent. A couple of things I've tried and the relevant conclusions: 1) After hotplugging a nic (eth1) on host0 via virsh (using the same source network/bridge), I've set a VLAN interface on top of it (eth1.600). Calling dhclient for eth1 worked; eth1.600 failed. I've tried this to rule out the cause being some configuration used in 005_network_by_label. 2) I've added a veth pair, with veth0 being added to Lago's bridge, and with having a VLAN interface (using the same ID) on top of veth1 (veth1.600) dnsmasq was set to listen on/serve veth1.600 without any success, although the VLAN tag is effectively removed. Similarly, DHCPDISCOVER(s) are being received, without any offers being sent. After setting an address manually on eth0.600, I was able to ping veth1.600 <-> eth0.600. Thanks, Leon

2 1

Where is ovirt-engine-sdk-python ?
by Yaniv Kaul 07 Dec '16

07 Dec '16

For some reason, both Hosted Engine and 4.0 ovirt-system-tests suites fail to find the v3 ovirt-engine-sdk-python RPM. I'm pretty sure it was OK yesterday. I do see it in the repos, the failure is: Error: Package: ovirt-engine-cli-3.6.9.2-1.el7.centos.noarch (alocalsync) Requires: ovirt-engine-sdk-python >= 3.6.0.0 However, I do have it: [ykaul@ykaul reposync]$ find . -name "ovirt-engine-cli-3.6.9.2-1.el7.centos.noarch*" ./ovirt-4.0-snapshot-el7/noarch/ovirt-engine-cli-3.6.9.2-1.el7.centos.noarch.rpm ./ovirt-master-snapshot-el7/noarch/ovirt-engine-cli-3.6.9.2-1.el7.centos.noarch.rpm [ykaul@ykaul noarch]$ find . -name "ovirt-engine-sdk-python-*" ./ovirt-engine-sdk-python-3.6.9.2-0.1.20161204.gite99bbd1.el7.centos.noarch.rpm And it's not copied to the deployment - could be a regression in the reposync? Y.

2 1

Deprecating Defaults for to_all_distros Setting in repoman
by Anton Marchukov 02 Dec '16

02 Dec '16

Hello All. If you use repoman please be aware that it currently has hardcoded list of packages that defaults to being distroless. This is controlled by "to_all_distros" configuration setting, but if you do not set it than the defaults are used. For ovirt experimental we decided that we better have all packages to have distro specified in spec. This also inline with most distro packaging guidelines. But then with current defaults repoman will consider those package to be distroless even when they are not and specifying an empty list in configuration is a silly way to override this. This change provides an incompatibility, but you can still use this feature by specifying to_all_distros package list explicitly in the config. So it is just the change of default values at this point: https://gerrit.ovirt.org/#/c/67662/ If somebody is not ok with defaults change and need time to update configuration please let me know. Also if you are not sure we can go another way and have intermediate repoman version that does not do the change, but issue deprecation warning if defaults are being used, so everybody can test their setups. However I think that it is might not be actually needed in this case as it is a configuration thing. Please feel free to comment on change request. Anton. -- Anton Marchukov Senior Software Engineer - RHEV CI - Red Hat

2 2