Re: [ovirt-devel] [ OST Failure Report ] [ oVirt Master] [ 09/08/2017 ] [ 001_upgrade_engine.test_initialize_engine ]

2017-08-09 Thread Eyal Edri 
Dafna,
Can we check why that package isn't coming from the centos-ops-testing repo?

Its availalbe:
https://buildlogs.centos.org/centos/7/opstools/x86_64/logging/rubygem-fluent-plugin-secure-forward-0.4.5-1.el7.noarch.rpm




On Wed, Aug 9, 2017 at 5:56 PM, Dafna Ron  wrote:

> Hi,
>
> We failed upgrade_engine.test_initialize_engine.
>
> the failure is caused by a package that I removed from the
> ovirt-snapshot-master for JIRA: OVIRT-1097
> 
>
> I restored the package and the tests should succeed.
>
> *Test failed: 001_upgrade_engine.test_initialize_engine*
>
>
>
> * Link to suspected patches: Link to Job:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/1712
>  Link
> to all logs:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/1712/artifact/
> 
> Error snippet from the log:  *
>
> [ ERROR ] Yum [u'rubygem-fluent-plugin-secure-forward-0.4.5-1.el7.noarch 
> requires rubygem(resolve-hostname)']
> [ INFO  ] Yum Performing yum transaction rollback
> [ ERROR ] Failed to execute stage 'Environment customization': 
> [u'rubygem-fluent-plugin-secure-forward-0.4.5-1.el7.noarch requires 
> rubygem(resolve-hostname)']
>
> **
>
>
> * Thanks, *
>
> Dafna
>
>
>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 

Eyal edri


ASSOCIATE MANAGER

RHV DevOps

EMEA VIRTUALIZATION R


Red Hat EMEA 
 TRIED. TESTED. TRUSTED. 
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [ OST Failure Report ] [ oVirt Master] [ 09/08/2017 ] [ 001_upgrade_engine.test_initialize_engine ]

2017-08-09 Thread Dafna Ron 
Hi,

We failed upgrade_engine.test_initialize_engine. 

the failure is caused by a package that I removed from the
ovirt-snapshot-master for JIRA: OVIRT-1097


I restored the package and the tests should succeed.

**

*Test failed:*001_upgrade_engine.test_initialize_engine**

*

Link to suspected patches:

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

Link to all logs:
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/1712/artifact/


Error snippet from the log:




*

[ ERROR ] Yum [u'rubygem-fluent-plugin-secure-forward-0.4.5-1.el7.noarch 
requires rubygem(resolve-hostname)']
[ INFO  ] Yum Performing yum transaction rollback
[ ERROR ] Failed to execute stage 'Environment customization': 
[u'rubygem-fluent-plugin-secure-forward-0.4.5-1.el7.noarch requires 
rubygem(resolve-hostname)']

**

**

*
Thanks,
*

Dafna*
*




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

[ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 09/08/2017 ] [ ovirt-hosted-engine-ha ]

2017-08-09 Thread Dafna Ron 
Hi,

We have a failure in ovirt-hosted-engine-ha which shows that project
ovirt-hosted-engine-ha_master_build-artifacts-el7-x86_64 has failed to
build.

in ovirt-hosted-engine-ha_master_build-artifacts-el7-x86_64 we have
failure due to package dependency.

**

**

*Test failed: *ovirt-hosted-engine-ha**

*

Link to suspected patches: https://gerrit.ovirt.org/#/c/78243/1

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

*

**

*Link to all logs: *

*

http://jenkins.ovirt.org/job/ovirt-hosted-engine-ha_master_build-artifacts-el7-x86_64/63/artifact/


Error snippet from the log:



*

*In changeq test: 12:36:49* 
ovirt-hosted-engine-ha_master_build-artifacts-el7-x86_64 (63) failed building

In oviert-hosted-engine-ha:

*12:14:04* Error: Package: vdsm-4.20.2-47.gitef4630a.el7.centos.x86_64 
(ovirt-master-snapshot)
*12:14:04*Requires: glusterfs-fuse >= 3.10
*12:14:04*Available: glusterfs-fuse-3.7.9-12.el7.centos.x86_64 
(centos-base-el7)
*12:14:04*glusterfs-fuse = 3.7.9-12.el7.centos
*12:14:04* Error: Package: vdsm-4.20.2-47.gitef4630a.el7.centos.x86_64 
(ovirt-master-snapshot)
*12:14:04*Requires: glusterfs-cli >= 3.10
*12:14:04*Available: glusterfs-cli-3.7.9-12.el7.centos.x86_64 
(centos-base-el7)
*12:14:04*glusterfs-cli = 3.7.9-12.el7.centos

*
*

**

**

thanks,

Dafna



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

Re: [ovirt-devel] [proposal] deprecate VDSM ping in favor of ping2 and confirmConnectivity

2017-08-09 Thread Petr Horacek 
Method with saved caller's IP address is an option, but it would
require rewriting of network's connectivity check mechanism. We would
need to introduce some extra IPC between supervdsm and vdsm for this
IIUIC.

The reason for ping2 is backward compatibility. It is undocumented,
but Engine still depends on it and older versions will probably stay
like that. In case we remove the side-effect and old Engine calls new
ping1 it would never confirm network connectivity.

2017-08-08 15:19 GMT+02:00 Martin Sivak :
>>> A ping that has no side effects and a "watchdog" mechanism to confirm
>>> connectivity.
>>
>> This sounds as exactly the right solution right now.
>
> Just to clarify: Removing the undocumented side effects from ping. Not
> introducing ping2.
>
> Martin
>
> On Tue, Aug 8, 2017 at 10:47 AM, Martin Sivak  wrote:
>>> The proposed solution is focused on making sure a command does one thing and
>>> not two:
>>> A ping that has no side effects and a "watchdog" mechanism to confirm
>>> connectivity.
>>
>> This sounds as exactly the right solution right now.
>>
> Still someone could call conirmConnectivity, no?
>>
>> We do not protect any other endpoints that can cause the host to go
>> wild (storage or even setupNetworks). I agree with Edward it is the
>> responsibility of the caller to do the right thing. You need to be
>> root or have the certificate to talk to VDSM anyway.
>>
>> Martin
>>
>> On Tue, Aug 8, 2017 at 8:24 AM, Edward Haas  wrote:
>>>
>>>
>>> On Mon, Aug 7, 2017 at 11:06 PM, Nir Soffer  wrote:

 On Mon, Aug 7, 2017 at 5:28 PM Roy Golan  wrote:
>
> Still someone could call conirmConnectivity, no? so the state isn't
> guarded from localhost tinkering anyhow. If you really need a solution you
> can acuire a token for this operation by setupNetworks, and confirm
> connectivity with this token passed back.
>
> I'm not sure about the severity of the problem here, I'll let other
> reply, but I'm against this kind of solution.
>
>
>
> On Mon, 7 Aug 2017 at 15:32 Petr Horacek  wrote:
>>
>> Hello,
>>
>> current VDSM ping verb has a problem - it confirms network
>> connectivity as a side-effect. After Engine calls setupNetwork it
>> pings VDSM host to confirm that external network connectivity is not
>> broken. This prohibits other users to call ping from localhost since
>> it would confirm connectivity even though networking could be broken.


 Vdsm can save the client ip setting up the network. Getting a ping from
 this
 client can confirm that the connectivity was restored. pings from other
 hosts
 can be ignored.

 The client address is available in a thread local variable
 (context.client_host)
 during all api calls. see vdsm.common.api.context_string() for example
 usage.

 This infrastructure is available in 4.1.
>>>
>>>
>>> The proposed solution is focused on making sure a command does one thing and
>>> not two:
>>> A ping that has no side effects and a "watchdog" mechanism to confirm
>>> connectivity.
>>>
>>> Does it make sense to confirm connectivity from localhost? In many cases it
>>> probably does not,
>>> but there may be cases where it does make sense... it is not the
>>> functionality to determine what
>>> makes sense or not, it is the usage of it who has the responsibility to use
>>> it correctly.
>>>

 Nir

>>
>>
>> In order to fix this problem ping should be split to ping2 (which just
>> returns Success with no side-effect) and confirmConnectivity. Change
>> on VDSM side was introduced in [1], we still need to expose new verbs
>> in Engine.
>>
>> Regards,
>> Petr
>>
>> [1] https://gerrit.ovirt.org/#/c/80119/
>> ___
>> 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
> ___
> 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

[ovirt-devel] Fwd: Removing @DefaultValueAttribute

2017-08-09 Thread Miroslava Voglova 
Hi,

I am currently moving all option values from ConfigValues to database. It
should make this values more readable and less error prone, since all will
be in one place. Also it will allow engine-config to work with all
available options and provide a way to find out if option is versioned, or
has one general value.

But I encountered problem with unit tests. Some tests (tests that use
MockConfigRule e.g. NetworkInSyncWithVdsNetworkInterfaceTest) rely on
getting default value from ConfigUtilBase#getValue, which will no longer be
possible, because there will be no @DefaultValueAttribute. As I understand,
this tests cannot get values from database either.

Does someone have an idea how to solve this problem? I was thinking about
changing MockConfigRule to get values from 000_config.sql, but I am not
sure if this change won't cause some other issues.

Thanks,
Mirka
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel