[ovirt-devel] Lago v0.45 Release Announcement

2018-12-09 Thread Gal Ben Haim 
Hi All,

On behalf of the Lago team, I'm pleased to announce Lago v0.45 is available!
For a detailed release announcement please refer to our Github page at:
https://github.com/lago-project/lago/releases/tag/0.45

Resources
==
Lago Docs: http://lago.readthedocs.io/en/latest/
GitHub: https://github.com/lago-project/lago/
YUM Repository: http://resources.ovirt.org/repos/lago/stable/0.0/rpm/
Pypi: https://pypi.python.org/pypi/lago
Docker Hub: https://hub.docker.com/r/lagoproject/lago/
Changelog: https://lago.readthedocs.io/en/latest/_static/ChangeLog.txt

As always, if you find any problems, or willing to contribute, visit our
GitHub page.

Enjoy!

-- 
*GAL BEN HAIM*
RHV DEVOPS

-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/URFFHKK5L6DIG43GZMTQBZIW2V4FN5XH/

[ovirt-devel] Re: [Ovirt] [CQ weekly status] [30-11-2018]

2018-12-02 Thread Gal Ben Haim 
In order to not block other patches on CQ, I've sent [1] which will double
the amount of space on the ISCSI SD (with the patch it will have 40GB).

As a side note, we use the same configuration on the master suite, which
may explain
why we don't see the issue there.

[1] https://gerrit.ovirt.org/#/c/95922/

On Sun, Dec 2, 2018 at 5:41 PM Gal Ben Haim  wrote:

> Below you can find 2 jobs, one that succeeded and the other failed on the
> iscsi issue.
> Both were triggered by unrelated patches.
>
> Success -
> https://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/3546/
> Failure -
> https://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/3544/
>
>
> On Sun, Dec 2, 2018 at 2:37 PM Gal Ben Haim  wrote:
>
>> Raz, thanks for the investigation.
>> I'll send a patch for increasing the luns size.
>>
>> On Sun, Dec 2, 2018 at 1:27 PM Nir Soffer  wrote:
>>
>>> On Sun, Dec 2, 2018, 10:44 Raz Tamir >>
>>>> After some analysis, I think the bug we are seeing here is
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1588061
>>>> This applies for suspend/resume and also for a snapshot with memory.
>>>> Following the steps and considering that the iscsi storage domain is
>>>> only 20GB, this should be the reason for reaching ~4GB free space
>>>>
>>>
>>>
>>> OST configuration should change so it is will not fail because of such
>>> bugs.
>>>
>>
>> I disagree. the purpose of OST it to catch bugs, not covering them.
>>
>>>
>>> Iscsi storage can be created using sparse files, not consuming any
>>> resources until you write to the lvs, so having 100g storage domain cost
>>> nothing.
>>>
>>
>> OST use sparse files.
>>
>>>
>>> Nir
>>>
>>>
>>>> On Fri, Nov 30, 2018 at 10:01 PM Raz Tamir  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Nov 30, 2018, 21:57 Ryan Barry >>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Nov 30, 2018 at 2:31 PM Raz Tamir  wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Nov 30, 2018, 19:33 Dafna Ron >>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> This mail is to provide the current status of CQ and allow people
>>>>>>>> to review status before and after the weekend.
>>>>>>>> Please refer to below colour map for further information on the
>>>>>>>> meaning of the colours.
>>>>>>>>
>>>>>>>> *CQ-4.2*: RED (#1)
>>>>>>>>
>>>>>>>> I checked last date ovirt-engine and vdsm passed and moved packages
>>>>>>>> to tested as they are the bigger projects and it was on the 27-11-218.
>>>>>>>>
>>>>>>>> We have been having sporadic failures for most of the projects on
>>>>>>>> test check_snapshot_with_memory.
>>>>>>>> We have deducted that this is caused by a code regression in
>>>>>>>> storage based on the following things:
>>>>>>>> 1.Evgheni and Gal helped debug this issue to rule out lago and
>>>>>>>> infra issue as the cause of failure and both determined the issue is a 
>>>>>>>> code
>>>>>>>> regression - most likely in storage.
>>>>>>>> 2. The failure only happens on 4.2 branch.
>>>>>>>> 3. the failure itself is cannot run a vm due to low disk space in
>>>>>>>> storage domain and we cannot see any failures which would leave any
>>>>>>>> leftovers in the storage domain.
>>>>>>>>
>>>>>>> Can you please share the link to the execution?
>>>>>>>
>>>>>>
>>>>>> Here's an example of one run:
>>>>>> https://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/3550/
>>>>>>
>>>>>> The iSCSI storage domain starts emitting warnings about low storage
>>>>>> space immediately after removing the VmPool, but it's possible that the
>>>>>> storage domain is filling before that from some other call prior to that
>>>>>> which is still running, possibly the VM import.
>>>>>>
>>>>> Thanks Ryan, I'll try to help with debu

[ovirt-devel] Re: [Ovirt] [CQ weekly status] [30-11-2018]

2018-12-02 Thread Gal Ben Haim 
Below you can find 2 jobs, one that succeeded and the other failed on the
iscsi issue.
Both were triggered by unrelated patches.

Success - https://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/3546/
Failure - https://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/3544/


On Sun, Dec 2, 2018 at 2:37 PM Gal Ben Haim  wrote:

> Raz, thanks for the investigation.
> I'll send a patch for increasing the luns size.
>
> On Sun, Dec 2, 2018 at 1:27 PM Nir Soffer  wrote:
>
>> On Sun, Dec 2, 2018, 10:44 Raz Tamir >
>>> After some analysis, I think the bug we are seeing here is
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1588061
>>> This applies for suspend/resume and also for a snapshot with memory.
>>> Following the steps and considering that the iscsi storage domain is
>>> only 20GB, this should be the reason for reaching ~4GB free space
>>>
>>
>>
>> OST configuration should change so it is will not fail because of such
>> bugs.
>>
>
> I disagree. the purpose of OST it to catch bugs, not covering them.
>
>>
>> Iscsi storage can be created using sparse files, not consuming any
>> resources until you write to the lvs, so having 100g storage domain cost
>> nothing.
>>
>
> OST use sparse files.
>
>>
>> Nir
>>
>>
>>> On Fri, Nov 30, 2018 at 10:01 PM Raz Tamir  wrote:
>>>
>>>>
>>>>
>>>> On Fri, Nov 30, 2018, 21:57 Ryan Barry >>>
>>>>>
>>>>>
>>>>> On Fri, Nov 30, 2018 at 2:31 PM Raz Tamir  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Nov 30, 2018, 19:33 Dafna Ron >>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> This mail is to provide the current status of CQ and allow people to
>>>>>>> review status before and after the weekend.
>>>>>>> Please refer to below colour map for further information on the
>>>>>>> meaning of the colours.
>>>>>>>
>>>>>>> *CQ-4.2*: RED (#1)
>>>>>>>
>>>>>>> I checked last date ovirt-engine and vdsm passed and moved packages
>>>>>>> to tested as they are the bigger projects and it was on the 27-11-218.
>>>>>>>
>>>>>>> We have been having sporadic failures for most of the projects on
>>>>>>> test check_snapshot_with_memory.
>>>>>>> We have deducted that this is caused by a code regression in storage
>>>>>>> based on the following things:
>>>>>>> 1.Evgheni and Gal helped debug this issue to rule out lago and infra
>>>>>>> issue as the cause of failure and both determined the issue is a code
>>>>>>> regression - most likely in storage.
>>>>>>> 2. The failure only happens on 4.2 branch.
>>>>>>> 3. the failure itself is cannot run a vm due to low disk space in
>>>>>>> storage domain and we cannot see any failures which would leave any
>>>>>>> leftovers in the storage domain.
>>>>>>>
>>>>>> Can you please share the link to the execution?
>>>>>>
>>>>>
>>>>> Here's an example of one run:
>>>>> https://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/3550/
>>>>>
>>>>> The iSCSI storage domain starts emitting warnings about low storage
>>>>> space immediately after removing the VmPool, but it's possible that the
>>>>> storage domain is filling before that from some other call prior to that
>>>>> which is still running, possibly the VM import.
>>>>>
>>>> Thanks Ryan, I'll try to help with debugging this issue
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> Dan and Ryan are actively involved in trying to find the regression
>>>>>>> but the consensus is that this is a storage related regression and*
>>>>>>> we are having a problem getting the storage team to join us in debugging
>>>>>>> the issue. *
>>>>>>>
>>>>>>> I prepared a patch to skip the test in case we cannot get
>>>>>>> cooperation from storage team and resolve this regression in the next 
>>>>>>> few
>>>>>>> days:
>>>>>>> https://gerrit.ovirt.org/#/c/9

[ovirt-devel] Re: [Ovirt] [CQ weekly status] [30-11-2018]

2018-12-02 Thread Gal Ben Haim 
t;>>>>> ** green for more than 3 days may suggest we need a review of our
>>>>>> test coverage
>>>>>>
>>>>>>
>>>>>>1.
>>>>>>
>>>>>>1-3 days   GREEN (#1)
>>>>>>2.
>>>>>>
>>>>>>4-7 days   GREEN (#2)
>>>>>>3.
>>>>>>
>>>>>>Over 7 days GREEN (#3)
>>>>>>
>>>>>>
>>>>>> Yellow = intermittent failures for different projects but no lasting
>>>>>> or current regressions
>>>>>>
>>>>>> ** intermittent would be a healthy project as we expect a number of
>>>>>> failures during the week
>>>>>>
>>>>>> ** I will not report any of the solved failures or regressions.
>>>>>>
>>>>>>
>>>>>>1.
>>>>>>
>>>>>>Solved job failuresYELLOW (#1)
>>>>>>2.
>>>>>>
>>>>>>Solved regressions  YELLOW (#2)
>>>>>>
>>>>>>
>>>>>> Red = job has been failing
>>>>>>
>>>>>> ** Active Failures. The colour will change based on the amount of
>>>>>> time the project/s has been broken. Only active regressions would be
>>>>>> reported.
>>>>>>
>>>>>>
>>>>>>1.
>>>>>>
>>>>>>1-3 days  RED (#1)
>>>>>>2.
>>>>>>
>>>>>>4-7 days  RED (#2)
>>>>>>3.
>>>>>>
>>>>>>Over 7 days RED (#3)
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> --
>>>>
>>>> Ryan Barry
>>>>
>>>> Associate Manager - RHV Virt/SLA
>>>>
>>>> rba...@redhat.comM: +16518159306 IM: rbarry
>>>> <https://red.ht/sig>
>>>>
>>>
>>
>> --
>>
>>
>> Raz Tamir
>> Manager, RHV QE
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/6EFAA4LR743GLDGGNVCK2PEOHL7USLB7/
>>
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/ZNMZS7V2TLRRXTYJ4EQ3R44Z634IL62T/
>


-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/S4TKBOH5ZHW6EMW467MWOOCFPTRLHWEC/

[ovirt-devel] Re: Failures on master CQ effecting all projects - (missing packages}

2018-11-20 Thread Gal Ben Haim 
>>>>
>>>>>>> I am working on debugging and fixing the issue and will update once
>>>>>>> its resolved.
>>>>>>>
>>>>>>> Please note that since its effecting add_host all projects are
>>>>>>> effected.
>>>>>>>
>>>>>>> Jira logged: https://ovirt-jira.atlassian.net/browse/OVIRT-2581
>>>>>>>
>>>>>>> Thanks
>>>>>>> Dafna
>>>>>>>
>>>>>>> ___
>>>>>>> Devel mailing list -- devel@ovirt.org
>>>>>>> To unsubscribe send an email to devel-le...@ovirt.org
>>>>>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>>>>>> oVirt Code of Conduct:
>>>>>>> https://www.ovirt.org/community/about/community-guidelines/
>>>>>>> List Archives:
>>>>>>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/ZM4KAPHWFYIZ3XNBHP5MASBA7TASIZGT/
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Martin Perina
>>>>>> Associate Manager, Software Engineering
>>>>>> Red Hat Czech s.r.o.
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Martin Perina
>>>> Associate Manager, Software Engineering
>>>> Red Hat Czech s.r.o.
>>>>
>>>
>>
>> --
>> Martin Perina
>> Associate Manager, Software Engineering
>> Red Hat Czech s.r.o.
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/FKM7CJV2NWVJKG5SZVY766YKNOVJ5XLA/
>>
>
>
> --
>
> Eyal edri
>
>
> MANAGER
>
> RHV/CNV DevOps
>
> EMEA VIRTUALIZATION R
>
>
> 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)
>


-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/W2DXOAMMOEYAO5MWRNKHCRXUCOVEKO4P/

[ovirt-devel] Lago oVirt plugin v0.45 Release Announcement

2018-07-31 Thread Gal Ben Haim 
Hi All,

On behalf of the Lago team, I'm pleased to announce Lago oVirt plugin v0.45
is available!

For a detailed release announcement, please refer to our Github page at:
https://github.com/lago-project/lago-ost-plugin/releases/tag/0.45

Resources
==
Docs: http://lago-ost-plugin.readthedocs.io/en/latest/
GitHub: https://github.com/lago-project/lago-ost-plugin
YUM Repository: http://resources.ovirt.org/repos/lago/stable/0.0/rpm/
OST Docs: http://ovirt-system-tests.readthedocs.io/en/latest/
Changelog:
http://lago-ost-plugin.readthedocs.io/en/latest/_static/ChangeLog.txt

As always, if you find any issues, or willing to contribute, visit our
GitHub page.

Enjoy!

-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/Q25ZPLIRNMCRVPDTVRURTQXEGEGSGYF6/

[ovirt-devel] Re: ovirt-system-tests_he-basic-iscsi-suite-master fails due to timeout waiting for StoragePool to go up after vdsmd restart

2018-07-16 Thread Gal Ben Haim 
gt;>>
>>> while the ha agent try to get the hosted engine stats
>>>
>>> 2018-07-05 23:38:30,363-0400 WARN  (vdsm.Scheduler) [Executor] Worker 
>>> blocked: >> 'jsonrpc': '2.0', 'method': u'Host.getStats', 'id': 
>>> u'cddde340-37a8-4f72-a471-b5bc40c06a16'} at 0x7f262814ae90> timeout=60, 
>>> duration=600.00 at 0x7f262815c050> task#=0 at 0x7f262834b810>, traceback:
>>> File: "/usr/lib64/python2.7/threading.py", line 785, in __bootstrap
>>>   self.__bootstrap_inner()
>>> File: "/usr/lib64/python2.7/threading.py", line 812, in __bootstrap_inner
>>>   self.run()
>>> File: "/usr/lib64/python2.7/threading.py", line 765, in run
>>>   self.__target(*self.__args, **self.__kwargs)
>>> File: "/usr/lib/python2.7/site-packages/vdsm/common/concurrent.py", line 
>>> 195, in run
>>>   ret = func(*args, **kwargs)
>>> File: "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 301, in _run
>>>   self._execute_task()
>>> File: "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 315, in 
>>> _execute_task
>>>   task()
>>> File: "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 391, in 
>>> __call__
>>>   self._callable()
>>> File: "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 261, 
>>> in __call__
>>>   self._handler(self._ctx, self._req)
>>> File: "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 304, 
>>> in _serveRequest
>>>   response = self._handle_request(req, ctx)
>>> File: "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 344, 
>>> in _handle_request
>>>   res = method(**params)
>>> File: "/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line 202, in 
>>> _dynamicMethod
>>>   result = fn(*methodArgs)
>>> File: "", line 2, in getStats
>>> File: "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 49, in 
>>> method
>>>   ret = func(*args, **kwargs)
>>> File: "/usr/lib/python2.7/site-packages/vdsm/API.py", line 1409, in getStats
>>>   multipath=True)}
>>> File: "/usr/lib/python2.7/site-packages/vdsm/host/api.py", line 78, in 
>>> get_stats
>>>   ret['haStats'] = _getHaInfo()
>>> File: "/usr/lib/python2.7/site-packages/vdsm/host/api.py", line 176, in 
>>> _getHaInfo
>>>   stats = instance.get_all_stats()
>>> File: 
>>> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py", 
>>> line 94, in get_all_stats
>>>   stats = broker.get_stats_from_storage()
>>> File: 
>>> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
>>>  line 135, in get_stats_from_storage
>>>   result = self._proxy.get_stats()
>>> File: "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__
>>>   return self.__send(self.__name, args)
>>> File: "/usr/lib64/python2.7/xmlrpclib.py", line 1591, in __request
>>>   verbose=self.__verbose
>>> File: "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request
>>>   return self.single_request(host, handler, request_body, verbose)
>>> File: "/usr/lib64/python2.7/xmlrpclib.py", line 1303, in single_request
>>>   response = h.getresponse(buffering=True)
>>> File: "/usr/lib64/python2.7/httplib.py", line 1113, in getresponse
>>>   response.begin()
>>> File: "/usr/lib64/python2.7/httplib.py", line 444, in begin
>>>   version, status, reason = self._read_status()
>>> File: "/usr/lib64/python2.7/httplib.py", line 400, in _read_status
>>>   line = self.fp.readline(_MAXLINE + 1)
>>> File: "/usr/lib64/python2.7/socket.py", line 476, in readline
>>>   data = self._sock.recv(self._rbufsize) (executor:363)
>>>
>>>
>>> Andrej, I see the test has been added by you in commit
>>> e8d32f7375f2033b73544f47c1e1ca67abe8d35a
>>> I'm not sure about the purpose of this test but I don't understand why
>>> we are restarting the services on the host.
>>>
>>> Nir, Tal, any idea on why the storage pool is not getting up?
>>>
>>> I see vdsm is in recovery mode, I'm not sure if this was what the test was 
>>> supposed to do or if the intention was to cleanly shutdown vdsm and cleanly 
>>> restart it.
>>>
>>>
>>>
>>>
>>> --
>>>
>>> SANDRO BONAZZOLA
>>>
>>> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>>>
>>> Red Hat EMEA <https://www.redhat.com/>
>>>
>>> sbona...@redhat.com
>>> <https://red.ht/sig>
>>>
>>
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/
> message/QONCFDY7AEZH2SV2ZCWFGGYIBZIBFJWP/
>
>


-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/NAUCG6HINTYZ5RBKVAEQDCANYGI3WXEL/

[ovirt-devel] Lago v0.44 Release Announcement

2018-06-07 Thread Gal Ben Haim 
Hi All,

On behalf of the Lago team, I'm pleased to announce Lago v0.44 is available!
The current release adds support for Fedora 28.
For a detailed release announcement please refer to our Github page at:
https://github.com/lago-project/lago/releases/tag/0.44


Resources
==
Lago Docs: http://lago.readthedocs.io/en/latest/
GitHub: https://github.com/lago-project/lago/
YUM Repository: http://resources.ovirt.org/repos/lago/stable/0.0/rpm/
Pypi: https://pypi.python.org/pypi/lago
Changelog: https://lago.readthedocs.io/en/0.44/_static/ChangeLog.txt


As always, if you find any problems, or willing to contribute, visit our
GitHub page.

Enjoy!

-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/XJRCCRAMMM7KKRN5VDOI4SP4NI3GMDYD/

[ovirt-devel] [ OST Failure Report ] [ oVirt master (ovirt-engine) ] [ 03.06.18 ] [098_ovirt_provider_ovn.use_ovn_provider ]

2018-06-03 Thread Gal Ben Haim 
Specifically, it failed to unplug a nic from a VM.


Suspected patches:


https://gerrit.ovirt.org/#/c/91195/

Link to Job:


https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/8019/

Link to all logs:


https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/8019/artifact/exported-artifacts/basic-suit-master-el7/

(Relevant) error snippet from the log:



2018-06-03 06:35:30,764-04 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.HotUnplugNicVDSCommand]
(default task-1) [32c965fd] FINISH, HotUnplugNicVDSCommand, return: ,
log id: 18d9b4e9
2018-06-03 06:35:30,764-04 DEBUG
[org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
(default task-1) [32c965fd] method: runVdsCommand, params:
[HotUnplugNic, 
VmNicDeviceVDSParameters:{hostId='d0f5b521-ed04-4b9e-9524-7f8d4be842d0',
vm.vm_name='vm0',
nic='VmNic:{id='9419aca6-2fae-4851-a902-a6b5a88ac691',
vnicProfileId='8d12fcbb-23e8-432d-845a-ab2b97039955', speed='1',
type='3', macAddress='00:1a:4a:16:01:0e', linked='true',
vmId='ec4303e9-2b7a-451d-9f43-836c29767652', vmTemplateId='null'}',
vmDevice='VmDevice:{id='VmDeviceId:{deviceId='9419aca6-2fae-4851-a902-a6b5a88ac691',
vmId='ec4303e9-2b7a-451d-9f43-836c29767652'}', device='bridge',
type='INTERFACE', specParams='[]', address='', managed='true',
plugged='true', readOnly='false', deviceAlias='',
customProperties='[]', snapshotId='null', logicalName='null',
hostDevice='null'}'}], timeElapsed: 55ms
2018-06-03 06:35:30,765-04 ERROR
[org.ovirt.engine.core.bll.network.vm.ActivateDeactivateVmNicCommand]
(default task-1) [32c965fd] Command
'org.ovirt.engine.core.bll.network.vm.ActivateDeactivateVmNicCommand'
failed: EngineException:
org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
VDSGenericException: VDSErrorException: Failed to HotUnplugNicVDS,
error = General Exception: ('macAddr',), code = 100 (Failed with error
GeneralException and code 100)
2018-06-03 06:35:30,774-04 DEBUG
[org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
(default task-1) [32c965fd] method: get, params:
[d0f5b521-ed04-4b9e-9524-7f8d4be842d0], timeElapsed: 3ms
2018-06-03 06:35:30,781-04 DEBUG
[org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
(DefaultQuartzScheduler5) [] Rescheduling
DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterSyncJob.refreshLightWeightData#-9223372036854775795
as there is no unfired trigger.
2018-06-03 06:35:30,781-04 DEBUG
[org.ovirt.engine.core.utils.timer.FixedDelayJobListener]
(DefaultQuartzScheduler6) [] Rescheduling
DEFAULT.org.ovirt.engine.core.bll.gluster.GlusterServiceSyncJob.refreshGlusterServices#-9223372036854775801
as there is no unfired trigger.
2018-06-03 06:35:30,782-04 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-1) [32c965fd] EVENT_ID:
NETWORK_DEACTIVATE_VM_INTERFACE_FAILURE(1,015), Failed to unplug
Network Interface eth2 (VirtIO) from VM vm0. (User:
admin@internal-authz)
2018-06-03 06:35:30,791-04 DEBUG
[org.ovirt.engine.core.dal.dbbroker.PostgresDbEngineDialect$PostgresSimpleJdbcCall]
(default task-1) [32c965fd] Compiled stored procedure. Call string i





-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/IKQ7TCXNH4YR4HVBIX6S5LCNBI7KNA56/

[ovirt-devel] [ OST Failure Report ] [ hc-basic-suite-4.2 ] [30-05-2018 ] [ 002_bootstrap.add_hosts ]

2018-05-30 Thread Gal Ben Haim 
Hi,

4.2 Hyper-converged suite is failing on "add_hosts" test (host 1 deployment
failed).

Link to Job:


https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-tests_hc-basic-suite-4.2/215/


Link to all logs:


https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-tests_hc-basic-suite-4.2/215/artifact/exported-artifacts/


(Relevant) error snippet from the host deploy log:



2018-05-30 05:30:09,706-0400 DEBUG otopi.plugins.otopi.dialog.machine
dialog.__logString:204 DIALOG:SEND   **%EventStart STAGE misc
METHOD 
otopi.plugins.ovirt_host_deploy.hosted-engine.configureha.Plugin._set_ha_conf
(None)
2018-05-30 05:30:09,713-0400 ERROR
otopi.plugins.ovirt_host_deploy.hosted-engine.configureha
configureha._set_ha_conf:114 HA client was not imported
2018-05-30 05:30:09,713-0400 DEBUG otopi.context
context._executeMethod:143 method exception
Traceback (most recent call last):
  File "/tmp/ovirt-lQCcc6VFAV/pythonlib/otopi/context.py", line 133,
in _executeMethod
method['method']()
  File 
"/tmp/ovirt-lQCcc6VFAV/otopi-plugins/ovirt-host-deploy/hosted-engine/configureha.py",
line 116, in _set_ha_conf
_('Cannot resolve ovirt_hosted_engine_ha module')
RuntimeError: Cannot resolve ovirt_hosted_engine_ha module





-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/2IFLFTCFVCBYS657I6YVA37BLBUYGFMX/

[ovirt-devel] Re: Propose Dominik Holler as a Network-Backend Maintainer

2018-05-14 Thread Gal Ben Haim 
On Tue, May 1, 2018 at 10:54 AM, Alona Kaplan <alkap...@redhat.com> wrote:

> Hi all,
>
> Dominik Holler has been working on the oVirt project for more than 1.5
> years.
>
> To share some of Dominik's great stats -
> ~ 120 patches related to the network backend/ui
> ~ 95 patches for ovirt-provider-ovn
> ~ 44 vdsm patches
> ~ 80 bug fixes
>
> I want to also mention the contribution to OST.
Good luck !


> He was the feature owner of 'auto sync network provider', 'lldp-reporting'
> and 'network-filter-parameters'.
>
> For the last few months Dominik is helping review network-backend related
> patches and is doing a great and thorough work.
> Dominik showed a deep understanding of all the parts of code that he
> touched or reviewed.
> He learns fast, thorough and uncompromising.
>
> I've reviewed most of Dominik's engine related work (code and reviews).
> I trust his opinion and think he will be a good addition to the
> maintainers team.
>
> I would like to propose Dominik as a Network backend maintainer.
>
>
> Thanks,
> Alona.
>
> _______
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 17.04.18 ] [ 002_bootstrap.add_qos ]

2018-04-17 Thread Gal Ben Haim 
Hi,

>From last night, the Change Queue fails on every run because of "add_qos"
test.

>From the engine log:

2018-04-16 10:31:51,813-04 ERROR
[org.ovirt.engine.core.bll.CommandsFactory] (default task-30) [] An
exception has occurred while trying to create a command object for
command 'AddCpuQos' with parameters
'QosParametersBase:{commandId='ccb4d6f4-ca86-4706-921c-f87439e0550f',
user='null', commandType='Unknown'}': WELD-001407: Cannot declare an
injection point with a type variable: [BackedAnnotatedField] @Inject
private org.ovirt.engine.core.bll.qos.QosCommandBase.qosDao
at 
org.ovirt.engine.core.bll.qos.QosCommandBase.qosDao(QosCommandBase.java:0)


2018-04-16 10:31:51,819-04 ERROR
[org.ovirt.engine.core.bll.CommandsFactory] (default task-30) []
Exception: org.jboss.weld.exceptions.DefinitionException: WELD-001407:
Cannot declare an injection point with a type variable:
[BackedAnnotatedField] @Inject private
org.ovirt.engine.core.bll.qos.QosCommandBase.qosDao
at 
org.ovirt.engine.core.bll.qos.QosCommandBase.qosDao(QosCommandBase.java:0)
  StackTrace
at 
org.jboss.weld.bootstrap.Validator.validateInjectionPointForDefinitionErrors(Validator.java:295)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at 
org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at 
org.jboss.weld.bootstrap.Validator.validateProducer(Validator.java:400)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at 
org.jboss.weld.injection.producer.InjectionTargetService.validateProducer(InjectionTargetService.java:36)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at 
org.jboss.weld.manager.InjectionTargetFactoryImpl.validate(InjectionTargetFactoryImpl.java:135)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at 
org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:79)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at 
org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:69)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at 
org.jboss.weld.manager.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:1140)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at 
org.jboss.weld.util.ForwardingBeanManager.createInjectionTarget(ForwardingBeanManager.java:201)
[weld-core-impl-2.4.3.Final.jar:2.4.3.Final]
at org.ovirt.engine.core.di.Injector.injectMembers(Injector.java:29)
[vdsbroker.jar:]
at 
org.ovirt.engine.core.bll.CommandsFactory.createCommand(CommandsFactory.java:100)
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:433) 
[bll.jar:]
at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:387) 
[bll.jar:]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.8.0_161]


Link to all logs:

http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6839/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/



-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [OST][HC] HE fails to deploy

2018-04-16 Thread Gal Ben Haim 
Any update on https://gerrit.ovirt.org/#/c/7/ ?
The HC suites still failing and it's hard to understand why without the
logs from the engine VM.

On Sat, Apr 7, 2018 at 7:19 AM, Sahina Bose <sab...@redhat.com> wrote:

>
>
> On Fri, Apr 6, 2018 at 1:10 PM, Simone Tiraboschi <stira...@redhat.com>
> wrote:
>
>>
>>
>> On Fri, Apr 6, 2018 at 9:28 AM, Sahina Bose <sab...@redhat.com> wrote:
>>
>>> 2018-04-05 20:46:52,773-0400 INFO 
>>> otopi.ovirt_hosted_engine_setup.ansible_utils 
>>> ansible_utils._process_output:100 TASK [Get local VM IP]
>>> 2018-04-05 20:55:28,217-0400 DEBUG 
>>> otopi.ovirt_hosted_engine_setup.ansible_utils 
>>> ansible_utils._process_output:94 {u'_ansible_parsed': True, 
>>> u'stderr_lines': [], u'cmd': u"virsh -r net-dhcp-leases default | grep -i 
>>> 00:16:3e:24:d3:63 | awk '{ print $5 }' | cut -f1 -d'/'", u'end': 
>>> u'2018-04-05 20:55:28.046320', u'_ansible_no_log': False, u'stdout': u'', 
>>> u'changed': True, u'invocation': {u'module_args': {u'warn': True, 
>>> u'executable': None, u'_uses_shell': True, u'_raw_params': u"virsh -r 
>>> net-dhcp-leases default | grep -i 00:16:3e:24:d3:63 | awk '{ print $5 }' | 
>>> cut -f1 -d'/'", u'removes': None, u'creates': None, u'chdir': None, 
>>> u'stdin': None}}, u'start': u'2018-04-05 20:55:28.000470', u'attempts': 50, 
>>> u'stderr': u'', u'rc': 0, u'delta': u'0:00:00.045850', u'stdout_lines': []}
>>> 2018-04-05 20:55:28,318-0400 ERROR 
>>> otopi.ovirt_hosted_engine_setup.ansible_utils 
>>> ansible_utils._process_output:98 fatal: [localhost]: FAILED! => 
>>> {"attempts": 50, "changed": true, "cmd": "virsh -r net-dhcp-leases default 
>>> | grep -i 00:16:3e:24:d3:63 | awk '{ print $5 }' | cut -f1 -d'/'", "delta": 
>>> "0:00:00.045850", "end": "2018-04-05 20:55:28.046320", "rc": 0, "start": 
>>> "2018-04-05 20:55:28.000470", "stderr": "", "stderr_lines": [], "stdout": 
>>> "", "stdout_lines": []}
>>>
>>> Both the 4.2 and master suites are failing on getting local VM IP.
>>> Any idea what changed or if I have to change the test?
>>>
>>> thanks!
>>>
>>
>> Hi Sahina,
>> 4.2 and master suite non HC are correctly running this morning.
>> http://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovi
>> rt-system-tests_he-basic-ansible-suite-master/146/
>> http://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovi
>> rt-system-tests_he-basic-ansible-suite-4.2/76/
>>
>> I'll try to check the difference with HC suites.
>>
>> Are you using more than one subnet in the HC suites?
>>
>
> No, I'm not. And we havent's changed anything related to network in the
> test suite.
>
>
>


-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt 4.2 ] [ 2018-04-04 ] [006_migrations.prepare_migration_attachments_ipv6]

2018-04-10 Thread Gal Ben Haim 
I'm seeing the same error in [1], during 006_migrations.migrate_vm.

[1] http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1650/

On Tue, Apr 10, 2018 at 4:14 PM, Alona Kaplan <alkap...@redhat.com> wrote:

> Hi all,
>
> Looking at the log it seems that the new GetCapabilitiesAsync is
> responsible for the mess.
>
> -
> * 08:29:47 - engine loses connectivity to host 'lago-basic-suite-4-2-host-0'.*
>
>
>
> *- Every 3 seconds a getCapabalititiesAsync request is sent to the host 
> (unsuccessfully).*
>
>  * before each "getCapabilitiesAsync" the monitoring lock is taken 
> (VdsManager,refreshImpl)
>
>  * "getCapabilitiesAsync" immediately fails and throws 
> 'VDSNetworkException: java.net.ConnectException: Connection refused'. The 
> exception is caught by 
> 'GetCapabilitiesAsyncVDSCommand.executeVdsBrokerCommand' which calls 
> 'onFailure' of the callback and re-throws the exception.
>
>  catch (Throwable t) {
> getParameters().getCallback().onFailure(t);
> throw t;
>  }
>
> * The 'onFailure' of the callback releases the "monitoringLock" 
> ('postProcessRefresh()->afterRefreshTreatment()-> if (!succeeded) 
> lockManager.releaseLock(monitoringLock);')
>
> * 'VdsManager,refreshImpl' catches the network exception, marks 
> 'releaseLock = true' and *tries to release the already released lock*.
>
>   The following warning is printed to the log -
>
>   WARN  [org.ovirt.engine.core.bll.lock.InMemoryLockManager] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-53) [] Trying to release 
> exclusive lock which does not exist, lock key: 
> 'ecf53d69-eb68-4b11-8df2-c4aa4e19bd93VDS_INIT'
>
>
>
>
> *- 08:30:51 a successful getCapabilitiesAsync is sent.*
>
>
> *- 08:32:55 - The failing test starts (Setup Networks for setting ipv6).*
>
> * SetupNetworks takes the monitoring lock.
>
> *- 08:33:00 - ResponseTracker cleans the getCapabilitiesAsync requests from 4 
> minutes ago from its queue and prints a VDSNetworkException: Vds timeout 
> occured.*
>
>   * When the first request is removed from the queue 
> ('ResponseTracker.remove()'), the
> *'Callback.onFailure' is invoked (for the second time) -> monitoring lock is 
> released (the lock taken by the SetupNetworks!).*
>
>   * *The other requests removed from the queue also try to release the 
> monitoring lock*, but there is nothing to release.
>
>   * The following warning log is printed -
> WARN  [org.ovirt.engine.core.bll.lock.InMemoryLockManager] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-14) [] Trying to release 
> exclusive lock which does not exist, lock key: 
> 'ecf53d69-eb68-4b11-8df2-c4aa4e19bd93VDS_INIT'
>
> - *08:33:00 - SetupNetwork fails on Timeout ~4 seconds after is started*. 
> Why? I'm not 100% sure but I guess the late processing of the 
> 'getCapabilitiesAsync' that causes losing of the monitoring lock and the late 
> + mupltiple processing of failure is root cause.
>
>
> Ravi, 'getCapabilitiesAsync' failure is treated twice and the lock is trying 
> to be released three times. Please share your opinion regarding how it should 
> be fixed.
>
>
> Thanks,
>
> Alona.
>
>
>
>
>
>
> On Sun, Apr 8, 2018 at 1:21 PM, Dan Kenigsberg <dan...@redhat.com> wrote:
>
>> On Sun, Apr 8, 2018 at 9:21 AM, Edward Haas <eh...@redhat.com> wrote:
>>
>>>
>>>
>>> On Sun, Apr 8, 2018 at 9:15 AM, Eyal Edri <ee...@redhat.com> wrote:
>>>
>>>> Was already done by Yaniv - https://gerrit.ovirt.org/#/c/89851.
>>>> Is it still failing?
>>>>
>>>> On Sun, Apr 8, 2018 at 8:59 AM, Barak Korren <bkor...@redhat.com>
>>>> wrote:
>>>>
>>>>> On 7 April 2018 at 00:30, Dan Kenigsberg <dan...@redhat.com> wrote:
>>>>> > No, I am afraid that we have not managed to understand why setting
>>>>> and
>>>>> > ipv6 address too the host off the grid. We shall continue researching
>>>>> > this next week.
>>>>> >
>>>>> > Edy, https://gerrit.ovirt.org/#/c/88637/ is already 4 weeks old, but
>>>>> > could it possibly be related (I really doubt that)?
>>>>> >
>>>>>
>>>>
>>> Sorry, but I do not see how this problem is related to VDSM.
>>> There is nothing that indicates that there is a VDSM problem.
>>>
>>> Has the RPC connection between Engine and VDSM failed?
>>>
>>>
>> Further up the thread, Piotr noticed that (at least on one failure of
>> this test) that the Vdsm host lost connectivity to its storage, and Vdsm
>> process was restarted. However, this does not seems to happen in all cases
>> where this test fails.
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt 4.2 ] [ 2018-04-04 ] [006_migrations.prepare_migration_attachments_ipv6]

2018-04-04 Thread Gal Ben Haim 
>From lago's log, I see that lago collected the logs from the VMs using ssh
(after the test failed), which means
that the VM didn't crash.

On Wed, Apr 4, 2018 at 5:27 PM, Dan Kenigsberg <dan...@redhat.com> wrote:

> On Wed, Apr 4, 2018 at 4:59 PM, Barak Korren <bkor...@redhat.com> wrote:
> > Test failed: [ 006_migrations.prepare_migration_attachments_ipv6 ]
> >
> > Link to suspected patches:
> > (Probably unrelated)
> > https://gerrit.ovirt.org/#/c/89812/1 (ovirt-engine-sdk) - examples:
> > export template to an export domain
> >
> > This seems to happen multiple times sporadically, I thought this would
> > be solved by
> > https://gerrit.ovirt.org/#/c/89781/ but it isn't.
>
> right, it is a completely unrelated issue there (with external networks).
> here, however, the host dies while setting setupNetworks of an ipv6
> address. Setup network waits for Engine's confirmation at 08:33:00,711
> http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/
> 1537/artifact/exported-artifacts/basic-suit-4.2-el7/
> test_logs/basic-suite-4.2/post-006_migrations.py/lago-
> basic-suite-4-2-host-0/_var_log/vdsm/supervdsm.log
> but kernel messages stop at 08:33:23
> http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/
> 1537/artifact/exported-artifacts/basic-suit-4.2-el7/
> test_logs/basic-suite-4.2/post-006_migrations.py/lago-
> basic-suite-4-2-host-0/_var_log/messages/*view*/
>
> Does the lago VM of this host crash? pause?
>
>
> >
> > Link to Job:
> > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1537/
> >
> > Link to all logs:
> > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/
> 1537/artifact/exported-artifacts/basic-suit-4.2-el7/
> test_logs/basic-suite-4.2/post-006_migrations.py/
> >
> > Error snippet from log:
> >
> > 
> >
> > Traceback (most recent call last):
> >   File "/usr/lib64/python2.7/unittest/case.py", line 369, in run
> > testMethod()
> >   File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in
> runTest
> > self.test(*self.arg)
> >   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
> > 129, in wrapped_test
> > test()
> >   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
> > 59, in wrapper
> > return func(get_test_prefix(), *args, **kwargs)
> >   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
> > 78, in wrapper
> > prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs
> >   File "/home/jenkins/workspace/ovirt-4.2_change-queue-tester/
> ovirt-system-tests/basic-suite-4.2/test-scenarios/006_migrations.py",
> > line 139, in prepare_migration_attachments_ipv6
> > engine, host_service, MIGRATION_NETWORK, ip_configuration)
> >   File "/home/jenkins/workspace/ovirt-4.2_change-queue-tester/
> ovirt-system-tests/basic-suite-4.2/test_utils/network_utils_v4.py",
> > line 71, in modify_ip_config
> > check_connectivity=True)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py",
> > line 36729, in setup_networks
> > return self._internal_action(action, 'setupnetworks', None,
> > headers, query, wait)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 299, in _internal_action
> > return future.wait() if wait else future
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 55, in wait
> > return self._code(response)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 296, in callback
> > self._check_fault(response)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 132, in _check_fault
> > self._raise_error(response, body)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 118, in _raise_error
> > raise error
> > Error: Fault reason is "Operation Failed". Fault detail is "[Network
> > error during communication with the Host.]". HTTP response code is
> > 400.
> >
> >
> >
> > 
> >
> >
> >
> > --
> > Barak Korren
> > RHV DevOps team , RHCE, RHCi
> > Red Hat EMEA
> > redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
> >
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Lago v0.43 Release Announcement

2018-04-03 Thread Gal Ben Haim 
Hi All,

On behalf of the Lago team, I'm pleased to announce Lago v0.43 is available!
For a detailed release announcement please refer to our Github page at:
https://github.com/lago-project/lago/releases/tag/0.43


Resources
==
Lago Docs: http://lago.readthedocs.io/en/latest/
GitHub: https://github.com/lago-project/lago/
YUM Repository: http://resources.ovirt.org/repos/lago/stable/0.0/rpm/
Pypi: https://pypi.python.org/pypi/lago
Changelog: http://lago.readthedocs.io/en/0.43/_static/ChangeLog.txt


As always, if you find any problems, or willing to contribute, visit our
GitHub page.

Enjoy!

-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 27-03-2018 ] [ 004_basic_sanity.disk_operations ]

2018-03-28 Thread Gal Ben Haim 
On Wed, Mar 28, 2018 at 2:48 PM, Benny Zlotnik <bzlot...@redhat.com> wrote:

> https://gerrit.ovirt.org/#/c/89534/
> https://gerrit.ovirt.org/#/c/89537/
>

Merged.

>
>
> On Wed, Mar 28, 2018 at 12:01 PM, Dafna Ron <d...@redhat.com> wrote:
>
>> Thanks Beni.
>>
>> can you please paste the fix that you submit to the mail?
>>
>> Thanks,
>> Dafna
>>
>>
>> On Wed, Mar 28, 2018 at 9:13 AM, Benny Zlotnik <bzlot...@redhat.com>
>> wrote:
>>
>>> This issue looks like it's caused by the DB lock being released before
>>> the engine memory lock, there was a similar race with the LSM test a few
>>> months back. I'll apply the same fix for the snapshot_cold_merge.
>>> .
>>>
>>> On Tue, Mar 27, 2018 at 10:03 PM, Benny Zlotnik <bzlot...@redhat.com>
>>> wrote:
>>>
>>>> Looking into this
>>>>
>>>> On Tue, Mar 27, 2018 at 6:45 PM, Dafna Ron <d...@redhat.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We have a failure on 004_basic_sanity.disk_operations. the reported
>>>>> change seems to me to be connected to the failure.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Link and headline of suspected patches: core: introduce
>>>>> CreateSnapshotForVm - https://gerrit.ovirt.org/#/c/87671/
>>>>> <https://gerrit.ovirt.org/#/c/87671/>Link to
>>>>> Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6564/
>>>>> <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6564/>Link
>>>>> to all
>>>>> logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6564/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-004_basic_sanity.py/
>>>>> <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/6564/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-004_basic_sanity.py/>(Relevant)
>>>>> error snippet from the log: 2018-03-27 11:30:16,167-04 WARN
>>>>> [org.ovirt.engine.core.bll.snapshots.CreateSnapshotForVmCommand] (default
>>>>> task-11) [9f713a3d-82a9-4db8-8207-bb69a0a2c550] Validation of action
>>>>> 'CreateSnapshotForVm' failed for user admin@internal-authz. Reasons:
>>>>> VAR__ACTION__CREATE,VAR__TYPE__SNAPSHOT,ACTION_TYPE_FAILED_SNAPSHOT_IS_BEING_TAKEN_FOR_VM,$VmName
>>>>> vm12018-03-27 11:30:16,176-04 DEBUG
>>>>> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
>>>>> (default task-11) [9f713a3d-82a9-4db8-8207-bb69a0a2c550] method: 
>>>>> runAction,
>>>>> params: [CreateSnapshotForVm,
>>>>> CreateSnapshotForVmParameters:{commandId='d8bfdb0e-5ae4-4fed-8852-a0b29e377708',
>>>>> user='null', commandType='Unknown',
>>>>> vmId='65e7fea5-8b7d-4281-bd0d-6a84de207a00'}], timeElapsed: 57ms2018-03-27
>>>>> 11:30:16,186-04 ERROR
>>>>> [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default
>>>>> task-11) [] Operation Failed: [Cannot create Snapshot. Snapshot is
>>>>> currently being created for VM vm1.]2018-03-27 11:30:16,820-04 INFO
>>>>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback]
>>>>> (EE-ManagedThreadFactory-engineScheduled-Thread-100)
>>>>> [16c08ce6-9a73-489f-a1f2-56e21699f14a] Command 'CopyImageGroupVolumesData'
>>>>> (id: '4c4023b4-21e8-4a98-8ac3-aba51967d160') waiting on child command id:
>>>>> '3d96b933-6e3b-4838-94bc-db3ff0cadcdc' type:'CopyData' to
>>>>> complete2018-03-27 11:30:16,833-04 DEBUG
>>>>> [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor]
>>>>> (EE-ManagedThreadFactory-engineScheduled-Thread-100)
>>>>> [16c08ce6-9a73-489f-a1f2-56e21699f14a] method: get, params:
>>>>> [a85992e9-40b8-4c80-9c93-3bf767f6efa4], timeElapsed: 8ms*
>>>>>
>>>>
>>>>
>>>
>>
>
> ___
> Infra mailing list
> in...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>


-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Lago oVirt plugin v0.44 Release Announcement

2018-01-24 Thread Gal Ben Haim 
Hi All,

On behalf of the Lago team, I'm pleased to announce Lago oVirt plugin v0.44
is available!

For a detailed release announcement, please refer to our Github page at:
https://github.com/lago-project/lago-ost-plugin/releases/tag/0.44

As always, if you find any issues, or willing to contribute, visit our
GitHub page.

Enjoy!

-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] OST Regression in add cluster (IBRS related)

2018-01-15 Thread Gal Ben Haim 
As a workaround, we can map *-IBRS: Intel * Family

On Mon, Jan 15, 2018 at 5:52 PM, Eyal Edri <ee...@redhat.com> wrote:

>
>
> On Mon, Jan 15, 2018 at 5:46 PM, Nadav Goldin <ngol...@virtual-gate.net>
> wrote:
>
>> Maybe related to [1]?
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1533125
>
>
> Seems like this is the cause.


> This is for RHEL 7.5, if its related then we should look at the 7.4.z
> clone:
>
> *Bug 1533418* <https://bugzilla.redhat.com/show_bug.cgi?id=1533418> - Libvirt
> may prefer $CPUModel over $CPUModel-IBRS when reporting host CPU model
> [rhel-7.4.z]
>
>
>>
>>
>>
>> On Mon, Jan 15, 2018 at 5:40 PM, Gal Ben Haim <gbenh...@redhat.com>
>> wrote:
>> > I've tried to run 'basic-suite-master' with [1], but I'm getting the
>> > following error:
>> >
>> > _ID: VDS_CPU_LOWER_THAN_CLUSTER(515), Host
>> lago-basic-suite-master-host-1
>> > moved to Non-Operational state as host does not meet the cluster's
>> minimum
>> > CPU level. Missing CPU features : model_Haswell-noTSX-IBRS
>> >
>> > When running virsh on the host I see the following CPU:
>> >
>> > Haswell-noTSX-IBRS
>> >
>> > The CPU definition in the dom xml of the host:
>> >
>> > 
>> > 
>> >   
>> >
>> >
>> > When running virsh on the VM (ovirt host) I see the following CPU:
>> >
>> > Haswell-noTSX
>> >
>> > Which doesn't match the CPU of the host.
>> >
>> > thoughts?
>> >
>> >
>> > [1] https://github.com/lago-project/lago-ost-plugin/pull/31
>> >
>> > On Sun, Jan 14, 2018 at 11:46 PM, Nadav Goldin <
>> ngol...@virtual-gate.net>
>> > wrote:
>> >>
>> >> Trying to put together what I remember:
>> >> 1. We had a QEMU bug where it was stated clearly that
>> >> nested-virtualization is only supported when using 'host-passthrough'
>> >> (don't know if that had changed since).
>> >> 2. As consequence of (1) - Lago uses by default host-passthrough.
>> >> 3. When running O-S-T, we needed a deterministic way to decide which
>> >> cluster level to use, taking into account that VDMS's CPU, can be,
>> >> theoretically, anything.
>> >> 4. That is why you see 'Skylake' and 'IvyBridge' there  -  to match
>> >> possible users of OST.
>> >> 5. Lago already uses 'virsh capabilities' to report the L1 VM's CPU,
>> >> lago-ost-plugin uses that report as the input key to the mapping file.
>> >>
>> >> As far as I remember, we settled for this method after several
>> >> on-going reports of users unable to run OST on their laptops due to
>> >> CPU issues.
>> >>
>> >>
>> >>
>> >> On Fri, Jan 12, 2018 at 6:49 PM, Michal Skrivanek
>> >> <michal.skriva...@redhat.com> wrote:
>> >> >
>> >> >
>> >> > On 12 Jan 2018, at 17:32, Yaniv Kaul <yk...@redhat.com> wrote:
>> >> >
>> >> >
>> >> >
>> >> > On Fri, Jan 12, 2018 at 1:05 PM, Michal Skrivanek
>> >> > <michal.skriva...@redhat.com> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On 12 Jan 2018, at 08:32, Tomas Jelinek <tjeli...@redhat.com>
>> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Fri, Jan 12, 2018 at 8:18 AM, Yaniv Kaul <yk...@redhat.com>
>> wrote:
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> On Fri, Jan 12, 2018 at 9:06 AM, Yaniv Kaul <yk...@redhat.com>
>> wrote:
>> >> >>>>
>> >> >>>> See[1] - do we need to update Lago / Lago OST plugin?
>> >> >>>
>> >> >>>
>> >> >>> Something like https://github.com/lago-projec
>> t/lago-ost-plugin/pull/31
>> >> >>> perhaps (not tested, don't have the HW).
>> >> >>
>> >> >>
>> >> >> yes, seems like that should do the trick.
>> >> >>
>> >> >>
>> >> >> sure, though, that list is also difficult to maintain
>> >> >> e.g. IvyBridge is not an oVirt supported model, there’s no “Skylake”
>> >> >> model
>> >> >>
>&g

Re: [ovirt-devel] OST Regression in add cluster (IBRS related)

2018-01-15 Thread Gal Ben Haim 
t; >>>> "/home/jenkins/workspace/ovirt-system-tests_master_
> check-patch-el7-x86_64/ovirt-system-tests/basic-suite-
> master/test-scenarios/002_bootstrap.py",
> >>>> line 277, in add_cluster
> >>>> add_cluster_4(prefix)
> >>>>   File
> >>>> "/home/jenkins/workspace/ovirt-system-tests_master_
> check-patch-el7-x86_64/ovirt-system-tests/basic-suite-
> master/test-scenarios/002_bootstrap.py",
> >>>> line 305, in add_cluster_4
> >>>> cpu_family = prefix.virt_env.get_ovirt_cpu_family()
> >>>>   File "/usr/lib/python2.7/site-packages/ovirtlago/virt.py", line
> 151,
> >>>> in get_ovirt_cpu_family
> >>>> ','.join(cpu_map[host.cpu_vendor].iterkeys())
> >>>> RuntimeError: Unsupported CPU model: Haswell-noTSX-IBRS. Supported
> >>>> models:
> >>>> IvyBridge,Westmere,Skylake,Penryn,Haswell,Broadwell,
> Nehalem,Skylake-Client,Broadwell-noTSX,Conroe,SandyBridge,Haswell-noTSX
> >>>>
> >>>>
> >>>>
> >>>> Y.
> >>>>
> >>>> [1]
> >>>> http://jenkins.ovirt.org/job/ovirt-system-tests_master_
> check-patch-el7-x86_64/3498/testReport/junit/(root)/002_
> bootstrap/add_cluster/
> >>>
> >>>
> >>>
> >>> ___
> >>> Devel mailing list
> >>> Devel@ovirt.org
> >>> http://lists.ovirt.org/mailman/listinfo/devel
> >>
> >>
> >> ___
> >> Devel mailing list
> >> Devel@ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/devel
> >
> >
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] OST Regression in add cluster (IBRS related)

2018-01-14 Thread Gal Ben Haim 
On Fri, Jan 12, 2018 at 7:07 PM, Yaniv Kaul <yk...@redhat.com> wrote:

>
>
> On Fri, Jan 12, 2018 at 6:49 PM, Michal Skrivanek <
> michal.skriva...@redhat.com> wrote:
>
>>
>>
>> On 12 Jan 2018, at 17:32, Yaniv Kaul <yk...@redhat.com> wrote:
>>
>>
>>
>> On Fri, Jan 12, 2018 at 1:05 PM, Michal Skrivanek <michal.skrivanek@re
>> dhat.com> wrote:
>>
>>>
>>>
>>> On 12 Jan 2018, at 08:32, Tomas Jelinek <tjeli...@redhat.com> wrote:
>>>
>>>
>>>
>>> On Fri, Jan 12, 2018 at 8:18 AM, Yaniv Kaul <yk...@redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jan 12, 2018 at 9:06 AM, Yaniv Kaul <yk...@redhat.com> wrote:
>>>>
>>>>> See[1] - do we need to update Lago / Lago OST plugin?
>>>>>
>>>>
>>>> Something like https://github.com/lago-project/lago-ost-plugin/pull/31 
>>>> perhaps
>>>> (not tested, don't have the HW).
>>>>
>>>
>>> yes, seems like that should do the trick.
>>>
>>>
>>> sure, though, that list is also difficult to maintain
>>> e.g. IvyBridge is not an oVirt supported model, there’s no “Skylake”
>>> model
>>>
>>> Nadav, what’s the exact purpose of that list, and can it be eliminated
>>> somehow?
>>>
>>
>> It's to match, as possible, between the host CPU (which is passed to L1)
>> so it'll match oVirt’s.
>>
>>
>> getting it from "virsh capabilities" on the host would match it a bit
>> better. It would be enough to just make the L1 host report (via fake caps
>> hook if needed) the same model_X in getVdsCapabilities as the L0
>>
>
1. Can you please explain how it can be achieved?
2. Will it eliminate the need to translate between the cpu model and the
cpu family?

>
> That used to be my initial implementation. I don't recall why it was
> changed.
> Y.
>
>
>>
>> It's not that difficult to maintain. We add new CPUs once-twice a year…?
>>
>>
>> yes, not often
>>
>> Y.
>>
>>
>>>
>>> Thanks,
>>> michal
>>>
>>>
>>>
>>>
>>>> Y.
>>>>
>>>>
>>>>> Error Message
>>>>>
>>>>> Unsupported CPU model: Haswell-noTSX-IBRS. Supported models: 
>>>>> IvyBridge,Westmere,Skylake,Penryn,Haswell,Broadwell,Nehalem,Skylake-Client,Broadwell-noTSX,Conroe,SandyBridge,Haswell-noTSX
>>>>>
>>>>> Stacktrace
>>>>>
>>>>> Traceback (most recent call last):
>>>>>   File "/usr/lib64/python2.7/unittest/case.py", line 369, in run
>>>>> testMethod()
>>>>>   File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in 
>>>>> runTest
>>>>> self.test(*self.arg)
>>>>>   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 129, 
>>>>> in wrapped_test
>>>>> test()
>>>>>   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 59, 
>>>>> in wrapper
>>>>> return func(get_test_prefix(), *args, **kwargs)
>>>>>   File 
>>>>> "/home/jenkins/workspace/ovirt-system-tests_master_check-patch-el7-x86_64/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py",
>>>>>  line 277, in add_cluster
>>>>> add_cluster_4(prefix)
>>>>>   File 
>>>>> "/home/jenkins/workspace/ovirt-system-tests_master_check-patch-el7-x86_64/ovirt-system-tests/basic-suite-master/test-scenarios/002_bootstrap.py",
>>>>>  line 305, in add_cluster_4
>>>>> cpu_family = prefix.virt_env.get_ovirt_cpu_family()
>>>>>   File "/usr/lib/python2.7/site-packages/ovirtlago/virt.py", line 151, in 
>>>>> get_ovirt_cpu_family
>>>>> ','.join(cpu_map[host.cpu_vendor].iterkeys())
>>>>> RuntimeError: Unsupported CPU model: Haswell-noTSX-IBRS. Supported 
>>>>> models: 
>>>>> IvyBridge,Westmere,Skylake,Penryn,Haswell,Broadwell,Nehalem,Skylake-Client,Broadwell-noTSX,Conroe,SandyBridge,Haswell-noTSX
>>>>>
>>>>>
>>>>>
>>>>> Y.
>>>>>
>>>>> [1] 
>>>>> http://jenkins.ovirt.org/job/ovirt-system-tests_master_check-patch-el7-x86_64/3498/testReport/junit/(root)/002_bootstrap/add_cluster/
>>>>>
>>>>>
>>>>
>>>> ___
>>>> Devel mailing list
>>>> Devel@ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>
>


-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Lago v0.42 Release Announcement

2017-12-06 Thread Gal Ben Haim 
Hi All,

On behalf of the Lago team, I'm pleased to announce Lago v0.42 is available!
For a detailed release announcement please refer to our Github page at:
https://github.com/lago-project/lago/releases/tag/0.42
<https://github.com/lago-project/lago/releases/tag/0.40>


Resources
==
Lago Docs: http://lago.readthedocs.io/en/latest/
GitHub: https://github.com/lago-project/lago/
YUM Repository: http://resources.ovirt.org/repos/lago/stable/0.0/rpm/
Pypi: https://pypi.python.org/pypi/lago
OST Docs: http://ovirt-system-tests.readthedocs.io/en/latest/
Changelog: http://lago.readthedocs.io/en/0.42/_static/ChangeLog.txt
<http://lago.readthedocs.io/en/0.40/_static/ChangeLog.txt>


As always, if you find any problems, or willing to contribute, visit our
GitHub page.

Enjoy!

-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Subject: [ OST Failure Report ] [ oVirt master ] [ 26.11.17 ] [ 001_initialize_engine ]

2017-11-26 Thread Gal Ben Haim 
Suspected patches:
https://gerrit.ovirt.org/#/c/84618/2

Link to Job:
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4158/

Link to all logs:
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4158/artifact/exported-artifacts/basic-suit-master-el7/

Error snippet from "ovirt-engine-setup.log":

017-11-26 11:48:42,863-0500 DEBUG
otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
plugin.execute:926 execute-output:
['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost',
'-p', '5432', '-u', 'engine', '-d', 'engine', '-l',
'/var/log/ovirt-engine/setup/ovirt-engine-setup-20171126114742-1yt09f.log',
'-c', 'apply'] stderr:
FATAL: Operation aborted, found duplicate version: 04020770

2017-11-26 11:48:42,863-0500 ERROR
otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema
schema._misc:374 schema.sh: FATAL: Operation aborted, found duplicate
version: 04020770
2017-11-26 11:48:42,863-0500 DEBUG otopi.context
context._executeMethod:143 method exception
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133,
in _executeMethod
method['method']()
  File 
"/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py",
line 376, in _misc
raise RuntimeError(_('Engine schema refresh failed'))
RuntimeError: Engine schema refresh failed
2017-11-26 11:48:42,864-0500 ERROR otopi.context
context._executeMethod:152 Failed to execute stage 'Misc
configuration': Engine schema refresh failed



-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 23-11-2017 ] [ 001_initialize_engine.test_initialize_engine ]

2017-11-26 Thread Gal Ben Haim 
The failure is not consistent.

On Sun, Nov 26, 2017 at 5:33 PM, Yaniv Kaul <yk...@redhat.com> wrote:

>
>
> On Sun, Nov 26, 2017 at 4:53 PM, Gal Ben Haim <gbenh...@redhat.com> wrote:
>
>> We still see this issue on the upgrade suite from latest release to
>> master [1].
>> I don't see any evidence in "/var/log/messages" [2] that
>> "ovirt-imageio-proxy" was started twice.
>>
>
> Since it's not a registered port and a high port, could it be used by
> something else (what are the odds though ?
> Is it consistent?
> Y.
>
>
>>
>> [1] http://jenkins.ovirt.org/blue/rest/organizations/jenkins
>> /pipelines/ovirt-master_change-queue-tester/runs/4153/
>> nodes/123/steps/241/log/?start=0
>>
>> [2] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovir
>> t-master_change-queue-tester/4153/artifact/exported-artifac
>> ts/upgrade-from-release-suit-master-el7/test_logs/upgrade-
>> from-release-suite-master/post-001_initialize_engine.py/
>> lago-upgrade-from-release-suite-master-engine/_var_log/messages/*view*/
>>
>> On Fri, Nov 24, 2017 at 8:16 PM, Dafna Ron <d...@redhat.com> wrote:
>>
>>> there were two different patches reported as failing cq today with the
>>> ovirt-imageio-proxy service failing to start.
>>>
>>> Here is the latest failure: http://jenkins.ovirt.org/job/o
>>> virt-master_change-queue-tester/4130/artifact
>>>
>>>
>>>
>>>
>>> On 11/23/2017 03:39 PM, Allon Mureinik wrote:
>>>
>>> Daniel/Nir?
>>>
>>> On Thu, Nov 23, 2017 at 5:29 PM, Dafna Ron <d...@redhat.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> We have a failing on test 001_initialize_engine.test_initialize_engine.
>>>>
>>>>
>>>> This is failing with error Failed to start service 'ovirt-imageio-proxy
>>>>
>>>>
>>>> *Link and headline ofto suspected patches: *
>>>>
>>>>
>>>> * build: Make resulting RPMs architecture-specific -
>>>> https://gerrit.ovirt.org/#/c/84534/ <https://gerrit.ovirt.org/#/c/84534/>
>>>> Link to Job:
>>>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4055
>>>> <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4055>*
>>>>
>>>>
>>>> *Link to all logs:*
>>>>
>>>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-teste
>>>> r/4055/artifact/
>>>>
>>>> *http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4055/artifact/exported-artifacts/upgrade-from-release-suit-master-el7/test_logs/upgrade-from-release-suite-master/post-001_initialize_engine.py/lago-upgrade-from-release-suite-master-engine/_var_log/messages/*view*/
>>>> <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4055/artifact/exported-artifacts/upgrade-from-release-suit-master-el7/test_logs/upgrade-from-release-suite-master/post-001_initialize_engine.py/lago-upgrade-from-release-suite-master-engine/_var_log/messages/*view*/>*
>>>>
>>>>
>>>>
>>>> * (Relevant) error snippet from the log:  *from lago log:
>>>>
>>>> Failed to start service 'ovirt-imageio-proxy
>>>>
>>>> messages logs:
>>>>
>>>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine systemd: 
>>>> Starting Session 8 of user root.
>>>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
>>>> ovirt-imageio-proxy: Traceback (most recent call last):
>>>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
>>>> ovirt-imageio-proxy: File "/usr/bin/ovirt-imageio-proxy", line 85, in 
>>>> 
>>>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
>>>> ovirt-imageio-proxy: status = image_proxy.main(args, config)
>>>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
>>>> ovirt-imageio-proxy: File 
>>>> "/usr/lib/python2.7/site-packages/ovirt_imageio_proxy/image_proxy.py", 
>>>> line 21, in main
>>>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
>>>> ovirt-imageio-proxy: image_server.start(config)
>>>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
>>>> ovirt-imageio-proxy: File 
>>>> "/usr/lib/python2.7/site-packages/ovirt_imageio_proxy/server.py", line 45, 
>>>> in start
>>>> Nov 23 07:30:4

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 23-11-2017 ] [ 001_initialize_engine.test_initialize_engine ]

2017-11-26 Thread Gal Ben Haim 
47 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: File "/usr/lib64/python2.7/SocketServer.py", line 430, 
>> in server_bind
>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: self.socket.bind(self.server_address)
>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: File "/usr/lib64/python2.7/socket.py", line 224, in meth
>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: return getattr(self._sock,name)(*args)
>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: socket.error: [Errno 98] Address already in use
>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine systemd: 
>> ovirt-imageio-proxy.service: main process exited, code=exited, 
>> status=1/FAILURE
>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine systemd: 
>> Failed to start oVirt ImageIO Proxy.
>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine systemd: Unit 
>> ovirt-imageio-proxy.service entered failed state.
>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine systemd: 
>> ovirt-imageio-proxy.service failed.
>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine systemd: 
>> ovirt-imageio-proxy.service holdoff time over, scheduling restart.
>> Nov 23 07:30:47 lago-upgrade-from-release-suite-master-engine systemd: 
>> Starting oVirt ImageIO Proxy...
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: Traceback (most recent call last):
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: File "/usr/bin/ovirt-imageio-proxy", line 85, in 
>> 
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: status = image_proxy.main(args, config)
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: File 
>> "/usr/lib/python2.7/site-packages/ovirt_imageio_proxy/image_proxy.py", line 
>> 21, in main
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: image_server.start(config)
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: File 
>> "/usr/lib/python2.7/site-packages/ovirt_imageio_proxy/server.py", line 45, 
>> in start
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: WSGIRequestHandler)
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: File "/usr/lib64/python2.7/SocketServer.py", line 419, 
>> in __init__
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: self.server_bind()
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: File "/usr/lib64/python2.7/wsgiref/simple_server.py", 
>> line 48, in server_bind
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: HTTPServer.server_bind(self)
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: File "/usr/lib64/python2.7/BaseHTTPServer.py", line 
>> 108, in server_bind
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: SocketServer.TCPServer.server_bind(self)
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: File "/usr/lib64/python2.7/SocketServer.py", line 430, 
>> in server_bind
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: self.socket.bind(self.server_address)
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: File "/usr/lib64/python2.7/socket.py", line 224, in meth
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: return getattr(self._sock,name)(*args)
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine 
>> ovirt-imageio-proxy: socket.error: [Errno 98] Address already in use
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine systemd: 
>> ovirt-imageio-proxy.service: main process exited, code=exited, 
>> status=1/FAILURE
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine systemd: 
>> Failed to start oVirt ImageIO Proxy.
>> Nov 23 07:30:48 lago-upgrade-from-release-suite-master-engine systemd: Unit 
>> ovirt-imageio-proxy.service

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt 4.1] [ 31 Oct 2017 ] [ 002_bootstrap.add_dc ]

2017-10-31 Thread Gal Ben Haim 
The thing that bothers me is why the deploy script returned status 0 even
though yum failed:

2017-10-31 11:18:14,496::ssh.py::ssh::58::lago.ssh::DEBUG::Running
2fed0ea0 on lago-basic-suite-4-1-host-0: bash -s < "#!/bin/bash -xe
yum -y install ovirt-host
rm -rf /dev/shm/*.rpm /dev/shm/yum
"
2017-10-31 11:18:16,121::ssh.py::ssh::81::lago.ssh::DEBUG::Command
2fed0ea0 on lago-basic-suite-4-1-host-0 returned with 0


On Tue, Oct 31, 2017 at 3:13 PM, Eyal Edri <ee...@redhat.com> wrote:

>
>
> On Tue, Oct 31, 2017 at 3:04 PM, Yaniv Kaul <yk...@redhat.com> wrote:
>
>> We shouldn't be installing ovirt-host (at the moment) in 4.1.
>> If we are, it's probably because I messed up somewhere...
>>
>
>> And it should not be installed ovirt-host-4.2.0 anyway (that's not my
>> fault, I hope!)
>> Y.
>>
>>
>> On Tue, Oct 31, 2017 at 1:57 PM, Dafna Ron <d...@redhat.com> wrote:
>>
>>> Hi,
>>>
>>> we had a failure in 002_bootstrap.add_dc in ovirt 4.1.
>>>
>>> I think that it's a dependency packaging issue for ruby-gem with the
>>> ovirt-host packages.
>>>
>>> *Link to suspected patches: https://gerrit.ovirt.org/#/c/83403/1
>>> <https://gerrit.ovirt.org/#/c/83403/1>*
>>>
>>> * Link to Job: *
>>>
>>> http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1227
>>>
>>>
>>> *Link to all logs:*
>>>
>>> *
>>> http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1227/testReport/junit/(root)/002_bootstrap/add_dc/
>>> <http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1227/testReport/junit/(root)/002_bootstrap/add_dc/>
>>> *
>>>
>>> *
>>> http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1227/artifact/exported-artifacts/basic-suit-4.1-el7/test_logs/basic-suite-4.1/post-002_bootstrap.py/lago_logs/lago.log
>>> <http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1227/artifact/exported-artifacts/basic-suit-4.1-el7/test_logs/basic-suite-4.1/post-002_bootstrap.py/lago_logs/lago.log>
>>> http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1227/artifact/
>>> <http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1227/artifact/>
>>> *
>>>
>>> * (Relevant) error snippet from the log: *
>>>
>>>
>>> *  *from the test:
>>>
>>> Error: The response content type 'text/html; charset=UTF-8' isn't the 
>>> expected JSON
>>>
>>> looking at the logs:
>>>
>>> ---> Package ruby-irb.noarch 0:2.0.0.648-30.el7 will be installed
>>> ---> Package rubygem-json.x86_64 0:1.7.7-30.el7 will be installed
>>> --> Finished Dependency Resolution
>>>  You could try using --skip-broken to work around the problem
>>>  You could try running: rpm -Va --nofiles --nodigest
>>>
>>> 2017-10-31 11:18:16,122::ssh.py::ssh::96::lago.ssh::DEBUG::Command 2fed0ea0 
>>> on lago-basic-suite-4-1-host-0  errors:
>>>  Error: Package: 
>>> ovirt-host-4.2.0-0.0.master.20171019135233.git1921fc6.el7.centos.noarch 
>>> (alocalsync)
>>>
>>> We need to findout why ovirt-host 4.2 is avaialble on 4.1 repo, this is
> probably the issue.
>
>
>>Requires: vdsm-client >= 4.20.0
>>>Available: vdsm-client-4.19.35-2.gitc1d5a55.el7.centos.noarch 
>>> (alocalsync)
>>>vdsm-client = 4.19.35-2.gitc1d5a55.el7.centos
>>> Error: Package: 
>>> ovirt-host-4.2.0-0.0.master.20171019135233.git1921fc6.el7.centos.noarch 
>>> (alocalsync)
>>>Requires: vdsm >= 4.20.0
>>>Available: vdsm-4.19.35-2.gitc1d5a55.el7.centos.x86_64 
>>> (alocalsync)
>>>vdsm = 4.19.35-2.gitc1d5a55.el7.centos
>>>
>>> **
>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
>
> Eyal edri
>
>
> MANAGER
>
> RHV DevOps
>
> EMEA VIRTUALIZATION R
>
>
> Red Hat EMEA <https://www.redhat.com/>
> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
> phone: +972-9-7692018 <+972%209-769-2018>
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt Master ] [ bootstrap.verify_add_hosts ] [ 18/10/17 ]

2017-10-19 Thread Gal Ben Haim 
Taken from the ansible-playbook log of host-0:

TASK [ovirt-host-deploy-firewalld : Enable firewalld rules] 
failed: [lago-basic-suite-master-host-0] (item={u'service': u'glusterfs'}) =>

{"changed": false, "failed": true, "item": {"service": "glusterfs"}, "msg":

"ERROR: Exception caught: org.fedoraproject.FirewallD1.Exception:

INVALID_SERVICE: 'glusterfs' not among existing services Permanent and
Non-Permanent(immediate)

operation, Services are defined by port/tcp relationship and named as
they are in /etc/services

(on most systems)"}


Shouldn't we fail the the playbook on firewall configuration failure?




On Thu, Oct 19, 2017 at 12:04 PM, Martin Perina <mper...@redhat.com> wrote:

>
>
> On Thu, Oct 19, 2017 at 10:58 AM, Dan Kenigsberg <dan...@redhat.com>
> wrote:
>
>> On Thu, Oct 19, 2017 at 10:29 AM, Martin Perina <mper...@redhat.com>
>> wrote:
>> >
>> >
>> > On Thu, Oct 19, 2017 at 7:35 AM, Dan Kenigsberg <dan...@redhat.com>
>> wrote:
>> >>
>> >> On Wed, Oct 18, 2017 at 2:40 PM, Daniel Belenky <dbele...@redhat.com>
>> >> wrote:
>> >>>
>> >>> Hi all,
>> >>>
>> >>> The following test is failing: 002_bootstrap.verify_add_hosts
>> >>> All logs from failing job
>> >>> Only 2 engine patches participated in the test, so the suspected
>> patches
>> >>> are:
>> >>>
>> >>> https://gerrit.ovirt.org/#/c/82542/2
>> >>> https://gerrit.ovirt.org/#/c/82545/3
>> >>>
>> >>> Due to the fact that when this error first introduced we had another
>> >>> error, the CI can't automatically detect the specific patch.
>> >>>
>> >>> Error snippet from logs: ovirt-host-deploy-ansible log (Full log)
>> >>>
>> >>> TASK [ovirt-host-deploy-firewalld : Enable firewalld rules]
>> >>> 
>> >>> failed: [lago-basic-suite-master-host-0] (item={u'service':
>> >>> u'glusterfs'}) => {"changed": false, "failed": true, "item":
>> {"service":
>> >>> "glusterfs"}, "msg": "ERROR: Exception caught:
>> >>> org.fedoraproject.FirewallD1.Exception: INVALID_SERVICE: 'glusterfs'
>> not
>> >>> among existing services Permanent and Non-Permanent(immediate)
>> operation,
>> >>> Services are defined by port/tcp relationship and named as they are in
>> >>> /etc/services (on most systems)"}
>> >>>
>> >>>
>> >>> Error from HOST 0 firewalld log:
>> >>> lago-basic-suite-master-host-0/_var_log/firewalld/ (Full log)
>> >>>
>> >>> 2017-10-15 16:51:24 ERROR: INVALID_SERVICE: 'glusterfs' not among
>> >>> existing services
>> >>
>> >>
>> >> Ondra, would such an error propagate through the playbook to Engine and
>> >> fail the add-host flow? (I think it should!)
>> >
>> >
>> > We didn't do that so far, because of EL 7.3
>> > . We need firewalld from 7.4 to have all available services in place (I
>> > don't remember but I think imageio service was the one delivered only in
>> > firewalld from 7.4). So  up until now we ingore non-existent firewalld
>> > service, but if needed we can turn this on and fail host deploy.
>>
>> Ok, so for now your "luckily" off the hook and not the reason of failure.
>>
>> >>
>> >>
>> >> Do you know which package provide the glusterfs firewalld service, and
>> why
>> >> it is missing from the host?
>> >
>> >
>> > So we have used 'glusterfs' firewalld service per Sahina recommendation,
>> > which is included in glusterfs-server package from version 3.7.6 [1].
>> But
>> > this package is not installed when installing packages for cluster with
>> > gluster capabilities enabled. So now I'm confused: don't we need
>> > glusterfs-server package? If not and we need those ports open because
>> they
>> > are used by services from different already installed glusterfs
>> packages,
>> > shouldn't the firewalld configuration be moved from glusterfs-server to
>> > glusterfs package?
>>
>> glusterfs-cli.rpm is required to consume gluster storage (virt use
>> case), but I don't recall that it needs open ports.
>>
>
> ​It was there even for IPTables, if gluster support is enabled on cluster,
> then gluster specific ports were enabled even with IPTables. FirewallD
> feature continues to use that.
> ​
>
>
>> glusterfs-server.rpm is required to provide gluster storage (gluster use
>> case).
>> If I recall correctly, firewalld feature has differentiated between
>> the two; opening needed ports only when relevant.
>>
>
> ​Right, but if gluster services are configured for firewalld it means that
> the host has been added to the cluster with gluster feature enabled and not
> only virt
> ​
>
>
>>
>> >
>> >
>> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1057295
>> >
>> >
>>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [ OST Failure Report ] [ oVirt basic master ] [ 25.09.17 ] [ add_dc ]

2017-09-25 Thread Gal Ben Haim 
/ovirt-master_change-queue-tester/

Link to the logs:
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2820/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/


-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [ OST Failure Report ] [ oVirt HE 4.1 ] [ 24.09.17 ] [ set_dc_quota_audit ]

2017-09-24 Thread Gal Ben Haim 
Hi All,

In the last days HE 4.1 suite is failing with the following error:

*RequestError:*

status: 409

reason: Conflict

detail: Cannot migrate MACs to another MAC pool, because that action would
create duplicates in target MAC pool, which are not allowed. Problematic
MACs are 54:52:c0:a8:c
8:63

The MAC above belongs to the HE VM.
HE-master works fine.

Can you please take a look?

*Link to Job:*
http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-4.1/

*Link to all logs*:
http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-4.1/42/artifact/exported-artifacts/


-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Lago v0.41 Release Announcement

2017-08-01 Thread Gal Ben Haim 
Hi All,

On behalf of the Lago team, I'm pleased to announce Lago v0.41 is available!
For a detailed release announcement please refer to our Github page at:
https://github.com/lago-project/lago/releases/tag/0.41

Resources
==
Lago Docs: http://lago.readthedocs.io/en/latest/
GitHub: https://github.com/lago-project/lago/
YUM Repository: http://resources.ovirt.org/repos/lago/stable/0.0/rpm/
Pypi: https://pypi.python.org/pypi/lago
OST Docs: http://ovirt-system-tests.readthedocs.io/en/latest/
Changelog: http://lago.readthedocs.io/en/0.41/_static/ChangeLog.txt
<http://lago.readthedocs.io/en/0.40/_static/ChangeLog.txt>


As always, if you find any problems, or willing to contribute, visit our
GitHub page.

Enjoy!

-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Fedora 26 Lago template is now available

2017-07-19 Thread Gal Ben Haim 
Hi All,

Fedora 26 Lago template is now available on [1].
The name of the template in the init file is "fc26-base".

[1] - http://templates.ovirt.org/repo

-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Lago v0.40 Release Announcement

2017-07-02 Thread Gal Ben Haim 
Hi All,

On behalf of the Lago team, I'm pleased to announce Lago v0.40 is available!
For a detailed release announcement please refer to our Github page at:
https://github.com/lago-project/lago/releases/tag/0.40


Resources
==
Lago Docs: http://lago.readthedocs.io/en/latest/
GitHub: https://github.com/lago-project/lago/
YUM Repository: http://resources.ovirt.org/repos/lago/stable/0.0/rpm/
Pypi: https://pypi.python.org/pypi/lago
OST Docs: http://ovirt-system-tests.readthedocs.io/en/latest/
Changelog: http://lago.readthedocs.io/en/0.40/_static/ChangeLog.txt


As always, if you find any problems, or willing to contribute, visit our
GitHub page.

Enjoy!

-- 
*GAL bEN HAIM*
RHV DEVOPS
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Lago v0.38 Release announcement

2017-04-27 Thread Gal Ben Haim 
Hi All,

On behalf of the Lago team, I'm pleased to announce Lago v0.38 is available!
This quick release is focused on improving lago-ovirt plugin.

Resources

Lago Docs:  http://lago.readthedocs.io/en/latest/
GitHub: https://github.com/lago-project/lago/
YUM Repository: http://resources.ovirt.org/repos/lago/stable/0.0/rpm/
OST Docs: http://ovirt-system-tests.readthedocs.io/en/latest/

Full Changelog:

* Thu Apr 27 2017 ovirt-infra  - 0.38.0
c9f53d4d: Merge pull request #525 from
  lago-project/do_not_export_dns_records
047b8e50: Remove dns entries from exported init file

* Thu Apr 27 2017 ovirt-infra  - 0.37.3
fcf0fcd3: Merge pull request #520 from
  lago-project/improve_lago_ovirt_status
5c864202: Improve lago ovirt status

* Thu Apr 27 2017 ovirt-infra  - 0.37.2
c5687ae0: Merge pull request #519 from
  lago-project/print_message_lago_ovirt_start
9cf732ef: Print informative message after "lago ovirt start"

* Thu Apr 27 2017 ovirt-infra  - 0.37.1
4520202d: Merge pull request #518 from
nvgoldin/increase_start_vm_timeout
33ca8c02: ovirtlago: reconfigure timeouts in 'lago ovirt start'

As always, if you find any problems, or willing to contribute, visit our
GitHub page.

Enjoy!

Gal.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 20-03-2017 ] [007_sd_reattach.reattach_storage_domain]

2017-03-20 Thread Gal Ben Haim 
I can see only one lago error, am I missing something ? moreover the job
stopped after this error,
otherwise 099_aaa-ldap would have run too.

ykaul - When do you think the test had to be stopped?

Adding the part of the log which relates to the failure:
https://paste.fedoraproject.org/paste/fe~KnbVCMZspDCAMkirmwV5M1UNdIGYhyRLivL9gydE=

On Mon, Mar 20, 2017 at 5:16 PM, Eyal Edri  wrote:

> Gal,
> Can you check if the fix in Lago to stop tests after the first failure
> worked here?
>
> On Mon, Mar 20, 2017 at 5:04 PM, Yaniv Kaul  wrote:
>
>> Too many issues to start diagnosing...
>> It begins with the previous issues - I wonder how it continued to run the
>> tests... Should have stopped.
>> Y.
>>
>> On Mon, Mar 20, 2017 at 3:53 PM, Shlomo Ben David 
>> wrote:
>>
>>> Hi,
>>>
>>>
>>> Test failed: [ 007_sd_reattach.reattach_storage_domain ]
>>>
>>> Link to suspected patches: N/A
>>> Link to Job: http://jenkins.ovirt.org/job/t
>>> est-repo_ovirt_experimental_master/5915/consoleFull
>>> Link to all logs: http://jenkins.ovirt.org/job/t
>>> est-repo_ovirt_experimental_master/5915/artifact/exported-ar
>>> tifacts/basic-suit-master-el7/test_logs/basic-suite-master/p
>>> ost-007_sd_reattach.py/
>>>
>>> Error snippet from the log:
>>>
>>> 
>>>
>>> 12:01:51 [basic_suit_el7] @ Run test: 007_sd_reattach.py: ERROR (in
>>> 0:00:44)
>>> 12:01:51 [basic_suit_el7] Error occured, aborting
>>> 12:01:51 [basic_suit_el7] Traceback (most recent call last):
>>> 12:01:51 [basic_suit_el7]   File 
>>> "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py",
>>> line 267, in do_run
>>> 12:01:51 [basic_suit_el7] self.cli_plugins[args.ovirtver
>>> b].do_run(args)
>>> 12:01:51 [basic_suit_el7]   File 
>>> "/usr/lib/python2.7/site-packages/lago/plugins/cli.py",
>>> line 184, in do_run
>>> 12:01:51 [basic_suit_el7] self._do_run(**vars(args))
>>> 12:01:51 [basic_suit_el7]   File 
>>> "/usr/lib/python2.7/site-packages/lago/utils.py",
>>> line 495, in wrapper
>>> 12:01:51 [basic_suit_el7] return func(*args, **kwargs)
>>> 12:01:51 [basic_suit_el7]   File 
>>> "/usr/lib/python2.7/site-packages/lago/utils.py",
>>> line 506, in wrapper
>>> 12:01:51 [basic_suit_el7] return func(*args, prefix=prefix, **kwargs)
>>> 12:01:51 [basic_suit_el7]   File 
>>> "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py",
>>> line 96, in do_ovirt_runtest
>>> 12:01:51 [basic_suit_el7] raise RuntimeError('Some tests failed')
>>> 12:01:51 [basic_suit_el7] RuntimeError: Some tests failed
>>>
>>> 
>>>
>>> Best Regards,
>>>
>>> Shlomi Ben-David | Software Engineer | Red Hat ISRAEL
>>> RHCSA | RHCVA | RHCE
>>> IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci)
>>>
>>> OPEN SOURCE - 1 4 011 && 011 4 1
>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
> Eyal Edri
> Associate Manager
> RHV DevOps
> EMEA ENG Virtualization R
> Red Hat Israel
>
> phone: +972-9-7692018 <+972%209-769-2018>
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel