- Devel - oVirt List Archives

Strange concurrency error on VM creation
by Marc Young 07 Mar '17

07 Mar '17

I've been fighting this for roughly two days and I'm starting to think that possibly it's not my code but an interaction with the server. I'm using test-kitchen[1] with the kitchen-vagrant[2] driver to spin up vagrant machines and run tests against them. I'm using Jenkins to run kitchen in containers in parallel. Basically Jenkins runs a docker container with ruby + vagrant 1.9.2 and runs kitchen test all at the same time as another container with ruby + vagrant 1.9.1. If I run these in parallel, on some occasions the server seems to respond with the wrong creation information. If you look at the logs here: http://home.blindrage.us:8080/job/myoung34/job/vagrant-ovirt4/view/change- requests/job/PR-79/41/console the container for vagrant 1.9.1 created a VM `vagrant-dynamic-1.9.1: [vagrant-1.9.1] Bringing machine 'default' up with 'ovirt4' provider... [vagrant-1.9.1] ==> default: Creating VM with the following settings... [vagrant-1.9.1] ==> default: -- Name: dynamic-1.9.1 And the container for vagrant 1.9.2 (nearly the same time) created a VM `vagrant-dynamic-1.9.2`: [vagrant-1.9.2] ==> default: Creating VM with the following settings... [vagrant-1.9.2] ==> default: -- Name: dynamic-1.9.2 [vagrant-1.9.2] ==> default: -- Cluster: Default If you look at the ss: the container 1.9.1 will wait for dynamic-1.9.1 and try to contact it at 192.168.2.54 the container 1.9.2 will wait for dynamic-1.9.2 and try to contact it at 192.168.2.55 But if you look at the logs, the 1.9.1 container started trying to work with 192.168.2.55 by creating a new key then talking to it: [vagrant-1.9.1] default: Key inserted! Disconnecting and reconnecting using new SSH key... [vagrant-1.9.1] Waiting for SSH service on 192.168.2.55:22, retrying in 3 seconds Because 1.9.1 inserted a generated key into that box, the 1.9.2 container which _should_ be talking to it cannot now: [vagrant-1.9.2] ==> default: Rsyncing folder: /home/jenkins/.kitchen/cache/ => /tmp/omnibus/cache [vagrant-1.9.2] SSH authentication failed! This is typically caused by the public/private [vagrant-1.9.2] keypair for the SSH user not being properly set on the guest VM. Please [vagrant-1.9.2] verify that the guest VM is setup with the proper public key, and that [vagrant-1.9.2] the private key path for Vagrant is setup properly as well. Via the ruby sdk I create the VM and store the ID it responded with. Then to get the IP: server = env[:vms_service].vm_service(env[:machine].id) nics_service = server.nics_service nics = nics_service.list ip_addr = nics.collect { |nic_attachment| env[:connection].follow_link(nic_attachment).reported_devices.collect { |dev| dev.ips.collect { |ip| ip.address if ip.version == 'v4' } } }.flatten.reject { |ip| ip.nil? }.first rescue nil Given this code I can't think of any way that I would get the wrong IP unless somehow the server responded incorrectly, since the NIC's i've scanned and compiled across are tied directly to the server I created. Any thoughts? This only happpens randomly and it seems to happen if I bombard the server with a bunch of VM creations simultaneously [1] https://github.com/test-kitchen/test-kitchen [2] https://github.com/test-kitchen/kitchen-vagrant

2 5

unboundid-ldapsdk-3.2.1 is available
by Sandro Bonazzola 07 Mar '17

07 Mar '17

Hi, upstream released a new version of unboundid-ldapsdk. Release notes are available at https://github.com/pingidentity/ldapsdk/releases/tag/3.2.1 Fedora packages will be available soon in testing repos for Fedora >= 25. Updates are available here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-7324baefd0 https://bodhi.fedoraproject.org/updates/FEDORA-2017-e111731937 If you test them, please provide karma. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 2

[ OST Failure Report ] [ oVirt 4.1 ] [ 07/02/17 ] [ add_secondary_storage_domains ]
by Daniel Belenky 07 Mar '17

07 Mar '17

*Test failed:* add_secondary_storage_domains *Link to failed Job: *test-repo_ovirt_experimental_4.1/889 <http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_exper…> *Link to all logs: *logs from Jenkins <http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_exper…> *Error snippet from log:* 2017-03-07 01:29:03,789::utils.py::_ret_via_queue::59::lago.utils::ERROR::Error while running thread Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/lago/utils.py", line 57, in _ret_via_queue queue.put({'return': func()}) File "/home/jenkins/workspace/test-repo_ovirt_experimental_4.1/ovirt-system-tests/basic-suite-4.1/test-scenarios/002_bootstrap.py", line 574, in add_iso_storage_domain add_generic_nfs_storage_domain(prefix, SD_ISO_NAME, SD_ISO_HOST_NAME, SD_ISO_PATH, sd_format='v1', sd_type='iso', nfs_version='v3') File "/home/jenkins/workspace/test-repo_ovirt_experimental_4.1/ovirt-system-tests/basic-suite-4.1/test-scenarios/002_bootstrap.py", line 437, in add_generic_nfs_storage_domain add_generic_nfs_storage_domain_4(prefix, sd_nfs_name, nfs_host_name, mount_path, sd_format, sd_type, nfs_version) File "/home/jenkins/workspace/test-repo_ovirt_experimental_4.1/ovirt-system-tests/basic-suite-4.1/test-scenarios/002_bootstrap.py", line 493, in add_generic_nfs_storage_domain_4 _add_storage_domain_4(api, p) File "/home/jenkins/workspace/test-repo_ovirt_experimental_4.1/ovirt-system-tests/basic-suite-4.1/test-scenarios/002_bootstrap.py", line 407, in _add_storage_domain_4 id=sd.id, File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py", line 3488, in add self._check_fault(response) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 98, in _check_fault Service._raise_error(response, fault) File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line 71, in _raise_error raise Error(msg) Error: Fault reason is "Operation Failed". Fault detail is "[Storage domain cannot be reached. Please ensure it is accessible from the host(s).]". HTTP response code is 400. -- *Daniel Belenky* *RHV DevOps* *Red Hat Israel*

2 1

[ OST Failure Report ] [ master ] [ 03.03.2017 ] [006_migrations host is in Connecting state]
by Pavel Zhukov 06 Mar '17

06 Mar '17

Hi, Migration is failed because host is in Connecting state. Seems like another jsonrpc related issue (Unrecognized message received). Job: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/5654/ Logs: http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/5654/artif… -- Pavel [LOGS SNIPPET] 2017-03-03 06:00:40,882-05 DEBUG [org.ovirt.vdsm.jsonrpc.client.reactors.Reactor] (SSL Stomp Reactor) [3155acab] Unable to process messages Unrecognized message received : org.ovirt.vdsm.jsonrpc.client.ClientConnectionException: Unrecognized message received 42965:2017-03-03 06:00:40,889-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler4) [] EVENT_ID: VDS_BROKER_COMMAND_FAILURE(10,802), Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VDSM lago-basic-suite-master-host1 command SpmStatusVDS failed: Unrecognized message received 42966:2017-03-03 06:00:40,889-05 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStatusVDSCommand] (DefaultQuartzScheduler4) [] Command 'SpmStatusVDSCommand(HostName = lago-basic-suite-master-host1, SpmStatusVDSCommandParameters:{runAsync='true', hostId='bba0ec26-4856-4389-982d-2ad68cb3f682', storagePoolId='8cc227da-70e7-4557-aa01-6d8ddee6f847'})' execution failed: VDSGenericException: VDSNetworkException: Unrecognized message received 42999:2017-03-03 06:00:40,925-05 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler4) [6c7fb340] EVENT_ID: SYSTEM_CHANGE_STORAGE_POOL_STATUS_PROBLEMATIC_WITH_ERROR(987), Correlation ID: 6c7fb340, Call Stack: null, Custom Event ID: -1, Message: Invalid status on Data Center test-dc. Setting Data Center status to Non Responsive (On host lago-basic-suite-master-host1, Error: Network error during communication with the Host.). 43457:2017-03-03 06:00:44,466-05 ERROR [org.ovirt.engine.core.bll.network.host.HostValidator] (default task-17) [14be0e43-97b8-4882-bbcc-27392543fae6] Unable to setup network: operation can only be done when Host status is one of: Maintenance, Up, NonOperational; current status is Connecting 43460:2017-03-03 06:00:44,476-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-17) [] Operation Failed: [Cannot setup Networks. Operation can be performed only when Host status is Maintenance, Up, NonOperational.]

3 8

[ OST Failure Report ] [ oVirt master ] [ 05/02/2017 ] [ assign_hosts_network_label ]
by Daniel Belenky 05 Mar '17

05 Mar '17

*Test failed:* assign_hosts_network_label *Link to failed Job:* - http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_exper… *Link to all logs: - * http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_exper… *Eror snippet from log:* RequestError: status: 409 reason: Conflict detail: Cannot add Label. Operation can be performed only when Host status is Maintenance, Up, NonOperational. -- *Daniel Belenky* *RHV DevOps* *Red Hat Israel*

3 2

Re: [ovirt-devel] rhevm listening on ipv6 ?
by Yevgeny Zaspitsky 05 Mar '17

05 Mar '17

Šimon, According to [1] oVirt should be accessible through IPv6 address. >From my experience engine web&rest can be accessed by using an URL with an IPv6 address in a browser. Please notice that an IPv6 literal address (not a hostname that resolves to an IPv6 address) in a valid URL should be wrapped by brackets, e.g. http:// [1::2]:80/path. You can verify that the engine listens to an IPv6 by running the following command from the Linux console of the host that runs ovirt-engine (while ovirt-engine service runs): netstat -lnp6 | grep <port> where <port> is the port ovirt-engine should be listening to and be accessed through (default is 80). It seems to me like a problem on ManageIQ side. Please let me know if you need further assistance. Regards, Yevgeny [1] https://bugzilla.redhat.com/show_bug.cgi?id=1310837 On Fri, Mar 3, 2017 at 4:55 PM, Šimon <simi(a)mykolab.com> wrote: > Hello Yevgeny, > > I am working on ipv6-only support for ManageIQ. And I have noticed that > providers QA has around listen on ipv4 only. > > Is it possible for rhevm web/api to listen on ipv6? What are the steps I > need to do? > > Thanks a lot! > ~š. >

1 0

Gerrit server restart
by Daniel Belenky 05 Mar '17

05 Mar '17

Hi all, The gerrit server will be unreachable due to a restart. Planned restart time: 11:20 (GMT +2) Sorry for the inconvenience, -- *Daniel Belenky* *RHV DevOps* *Red Hat Israel*

1 0

ovirt-js-dependencies - is it noarch or x86_64?
by Yaniv Kaul 04 Mar '17

04 Mar '17

I'm seeing: ovirt-master-tested-el7/noarch/ovirt-js-dependencies-0.0.3-4.el7.centos.noarch.rpm and: ovirt-master-tested-el7/x86_64/ovirt-js-dependencies-0.0.3-2.el7.centos.x86_64.rpm Don't we need just one? Y.

3 4

Re: [ovirt-devel] [rhev-tech] oVirt 4.1 deep dive - V4 Storage Type
by Dan Yasny 03 Mar '17

03 Mar '17

+1 fix the permissions please On Thu, Mar 2, 2017 at 10:01 AM, Marc Skinner <mskinner(a)redhat.com> wrote: > Can you fix the permissions on the video - I'm getting a permissions issue > when I try to view it. > > Thanks! > > > > On 03/02/2017 12:45 AM, Maor Lipchuk wrote: > >> Hi all, >> Thank you all for participating the deep dive yesterday >> >> The slides are here: >> http://redhat.slides.com/mlipchuk/v4-storage-type#/ >> >> The recorded video is here: >> https://redhat.bluejeans.com/playback/guid/MTM5NjI5ODgyNToyN >> TY3MTYtMmMyNzI4MTQtYWM4NS00ZDI4LWE0YTUtZTQ0ZGUyNzMyYWUz# >> >> I will upload it later to youtube. >> >> Thanks, >> Maor Lipchuk >> >> > > > -- > > Marc Skinner, RHCDS, RHCVA, RHCA [110-655-057] > Red Hat, Inc. Tried. Tested. Trusted. > > Principal Solutions Architect > cell :: 952.454.7811 > email :: mskinner(a)redhat.com > web :: http://people.redhat.com/mskinner > > >

3 3

OST: HE installation on 4.1 fails due to default cluster level
by Sahina Bose 03 Mar '17

03 Mar '17

Hi all, The ovirt-engine 4.1 appliance has the Default cluster set to 4.2 and the hyperconverged OST tests fail here as the 4.1 host cannot be added to cluster. (CLUSTER_VERSION_INCOMPATIBLE_WITH_CLUSTER) The appliance is from http://resources.ovirt.org/repos/ovirt/tested/master/rpm/el7/noarch/ovirt-e… Has the default cluster level been changed in an updated appliance? Test results at http://jenkins.ovirt.org/view/oVirt system tests/job/ovirt_4.1_hc-system-tests/1/artifact/exported-artifacts thanks sahina

4 5