March 2017 - Devel - oVirt List Archives

[ 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

About the doc and website
by Marc Dequènes (Duck) 02 Mar '17

02 Mar '17

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fbpbdxi90oGq1hbBHA1h5KWXPF8ktnt9J Content-Type: multipart/mixed; boundary="TDtgiSKijbDUNALA708IX3iruKjpKiAlG"; protected-headers="v1" From: =?UTF-8?B?TWFyYyBEZXF1w6huZXMgKER1Y2sp?= <duck(a)redhat.com> To: oVirt Infra <infra(a)ovirt.org>, devel <devel(a)ovirt.org> Message-ID: <e29c1310-e2b3-1fb9-b8c5-c550228b7732(a)redhat.com> Subject: About the doc and website --TDtgiSKijbDUNALA708IX3iruKjpKiAlG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Quack, (I'm not on devel@, so please keep me on Cc) OVIRT-1202 raised some interesting question about doc storage and resources. Part of it is related to a subject that was raised multiple times and I'd like to discuss. OSAS recently added the Gnocchi (http://gnocchi.xyz/) project to the hosted tenants in the Community Cage, and it was interesting discussing with the author about how they manage to have a clean documentation. On the technical side, Gnocchi uses Sphynx, the Python doc generator, and it seem to do a good job. They use tox to build for multiple versions. Seem a good example. The builder and site are hosted in the Cage and we use Ansible to deploy it. This was not a big job to get it working and we already received contributions, so I'm very happy with this deployment. On the organization side, the doc is maintained along with the code, not outside on some wiki or the like, so no feature or change is accepted unless the corresponding doc update it done. Doc builders are in charge of publishing the doc properly, and devs do not have to worry about it. So the idea of splitting the project presentation and marketing from the technical documentation seem to really make sense (currently all piled on on http://www.ovirt.org/) Also the workflow should prevent doc from lagging behind. Not only API doc, but guides should be part of it. As for team planning, and technical discussions or drafts which are not yet reality, I forgot to ask how they handle it. I don't know well how oVirt is coded, but that's general ideas based on successful other projects. People have been quite upset with the state of the documentation, and we (Garret, Bkp and me mostly) fixed a lot of broken links, lost assets=E2=80=A6 so maybe we could reboot this subject = peacefully. \_o< --TDtgiSKijbDUNALA708IX3iruKjpKiAlG-- --fbpbdxi90oGq1hbBHA1h5KWXPF8ktnt9J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcpcqg+UmRT3yiF+BVen596wcRD8FAli4V60ACgkQVen596wc RD+/fBAAhmXiovdzodTCCOM1RYMYgWJ5LU4l3TsUovUZ2s/Hkbsfody4lOJ+XiQQ FETx3bc84UYEh3ot8WE1qkwVAc2UZI/ToN4KMQqE9GyIeAliGYdgKwSE2HO+qgJI De2jpZv7JAuSZl8MgN5sw58mhmLygvKcTTB7XdzaFzwFpEyoDoM28YgBByu7Ni9D o0A67XxZjRYhAgp9+ITzL93FYhcoQ8t9FZocqK5RhhTvOgeCSkulwQq68BLHXnAA NmoramJ0YDJa6DwEZNH0dhj/VbtJCyhUttDdHuVUgucmuyDi7X1+8nMfBb6e3Zb2 8Ua20mLrCdBlfCbj5cdH72Hz8/fzgPbzuC46cdTaXubz3BxgL8bEwDCL4jssf28v Fy1qU8OUIpZsehfksH+wqwUAnQkZdBKoluiwnsn4QABBMAGpy8AssmUDUWasJOai XmxSO5XzrkCuJuiifE7RctaHp1ViMnSj6vtleKmFvyb0OpAZdYlbfE0OSSvA/fky ssAlPRmfS6SdwHpf3+QSM3ZGSzrs/cKXoyEQ9x7xrf5Teh98tdHgSgATDrN/Bzt9 ONhWX0JPq5Co31S0pb+fWAfIlAQRz0QN9TbDQvFP8R77dDzCn9W0qFgYxso1Aaph 8WW5R2MsZsD1WIvgtkrAF49ekdx/96aJ0X0lV+TJnU6/j474puI= =pGU4 -----END PGP SIGNATURE----- --fbpbdxi90oGq1hbBHA1h5KWXPF8ktnt9J--

1 0

[ OST Failure Report ] [ oVirt master ] [ 02.03.2017 ] [001_upgrade_engine.py]
by Pavel Zhukov 02 Mar '17

02 Mar '17

Hello, ovirt-engine upgrade is failed on 'rpm -q' command [2] so job [1] was marked as failed. It's reproducible and started from build [1] onward. I don't see any relevant patches in otopi/engine merged recently so no suspected patches sp far. [1] http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_exper… [2] 2017-03-02 02:48:13 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine_common.distro-rpm.packages plugin.execute:926 execute-output: ('/bin/rpm', '-q', 'ovirt-engine-webadmin-portal', 'ovirt-engine-dwh', 'ovirt-engine', 'ovirt-engine-restapi', 'ovirt-engine-dbscripts', 'ovirt-engine-tools-backup', 'ovirt-engine-dashboard', 'ovirt-engine-userportal', 'ovirt-engine-wildfly', 'ovirt-engine-backend', 'ovirt-engine-wildfly-overlay', 'ovirt-engine-hosts-ansible-inventory', 'ovirt-engine-tools', 'ovirt-engine-extension-aaa-jdbc') stderr: 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Yum Transaction' Loaded plugins: fastestmirror, versionlock 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'DWH Engine database Transaction' 2017-03-02 02:48:13 DEBUG otopi.transaction transaction.abort:119 aborting 'Database Transaction' 2017-03-02 02:48:13 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/otopi/plugins/otopi/core/transaction.py", line 93, in _main_end self._mainTransaction.commit() File "/usr/lib/python2.7/site-packages/otopi/transaction.py", line 148, in commit element.commit() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine-common/distro-rpm/packages.py", line 146, in commit osetupcons.RPMDistroEnv.VERSION_LOCK_APPLY File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 931, in execute command=args[0], RuntimeError: Command '/bin/rpm' failed to execute 2017-03-02 02:48:13 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Transaction commit': Command '/bin/rpm' failed to execute -- Pavel

5 8