[ovirt-devel] Re: Purging inactive maintainers from vdsm-master-maintainers

[Edward Haas]

On Sun, Jun 20, 2021 at 11:29 PM Nir Soffer  wrote:

> On Mon, Dec 2, 2019 at 4:27 PM Adam Litke  wrote:
>
>> I also agree with the proposal.  It's sad to turn in my keys but I'm
>> likely unable to perform many duties expected of a maintainer at this
>> point.  I know that people can still find me via the git history :)
>>
>> On Thu, Nov 28, 2019 at 3:37 AM Milan Zamazal 
>> wrote:
>>
>>> Dan Kenigsberg  writes:
>>>
>>> > On Wed, Nov 27, 2019 at 4:33 PM Francesco Romani 
>>> wrote:
>>> >>
>>> >> On 11/27/19 3:25 PM, Nir Soffer wrote:
>>> >
>>> >> > I want to remove inactive contributors from vdsm-master-maintainers.
>>> >> >
>>> >> > I suggest the simple rule of 2 years of inactivity for removing from
>>> >> > this group,
>>> >> > based on git log.
>>> >> >
>>> >> > See the list below for current status:
>>> >> > https://gerrit.ovirt.org/#/admin/groups/106,members
>>> >>
>>> >>
>>> >> No objections, keeping the list minimal and current is a good idea.
>>> >
>>> >
>>> > I love removing dead code; I feel a bit different about removing old
>>> > colleagues. Maybe I'm just being nostalgic.
>>> >
>>> > If we introduce this policy (which I understand is healthy), let us
>>> > give a long warning period (6 months?) before we apply the policy to
>>> > existing dormant maintainers. We should also make sure that we
>>> > actively try to contact a person before he or she is dropped.
>>>
>>> I think this is a reasonable proposal.
>>>
>>> Regards,
>>> Milan
>>>
>>
> I forgot about this, and another year passed.
>
> Sending again, this time I added all past maintainers that may not watch
> this list.
>

Very sad, but it makes total sense. +1
Note that other projects move past maintainers to a special group named
"emeritus_*".


> Nir
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/KRXVKDMF4NOZ7MXEPVBFXLEPABH3LQVO/

[ovirt-devel] Re: Propose Eitan Raviv as a ovirt-system-tests network-suite maintainer

[Edward Haas]

On Fri, Sep 25, 2020 at 6:23 PM Dominik Holler  wrote:
>
> Hi all,
> Eitan Raviv has been working on the oVirt project for more than 3 years.
> He contributed more than 40 patches to ovirt-system-tests, including
> more than 35 patches to the network-suite.
> He is already recognized as a relevant reviewer for the network-suite,
> so it time to give him the official role for the work he is already
> doing.
>
> I would like to propose Eitan as a virt-system-tests network-suite
> maintainer.

+1
Eitan is doing great work on OST, I'll be happy to see him taking over
and giving it the attention it deserves.

>
> Thanks
> Dominik
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/P27QSQM5YMQD5DXTLU7LTS4QXQVPGFIM/

[ovirt-devel] Re: sic transit gloria mundi

[Edward Haas]

Great milestone!

On Sun, Jul 5, 2020 at 9:25 PM Dan Kenigsberg  wrote:

> Seven years ago, in June 2013, Giuseppe Valarelli introduced
> tests/functional/networkTests.py in
> https://gerrit.ovirt.org/#/c/14840/. It held high aspirations: to
> provide a comprehensive functional test for Vdsm's network API, in
> order to ease development of new code and reduce chances of
> reintroducing old bugs.
>
> 390 commits later, Andrej Cernak removed the last lines of code from
> that file in https://gerrit.ovirt.org/#/c/109182/.
>
> In between, many many other developers contributed to the set of
> tests, and later dissipated its content to multiple pytest-driven test
> modules. tests/functional/networkTests.py was never an emblem of great
> software design; it makes me happy to see it gone. But it was very
> useful and its spirit lives on: API tests are now the rule of Vdsm
> development, not an exception.
>
> I'd like to thank all the people who made this possible.
>
> $ git log 1c5f15c9b~ -- tests/functional/networkTests.py|grep
> Author|sort|uniq -c|sort -nr
>  72 Author: Edward Haas 
>  58 Author: Ido Barkan 
>  46 Author: Ondřej Svoboda 
>  40 Author: Petr Horáček 
>  35 Author: Dan Kenigsberg 
>  34 Author: Antoni S. Puimedon 
>  24 Author: Bell Levin 
>  23 Author: Leon Goldberg 
>  18 Author: Giuseppe Vallarelli 
>   8 Author: Assaf Muller 
>   5 Author: Sveta Haas 
>   4 Author: Mark Wu 
>   3 Author: Nir Soffer 
>   2 Author: Yaniv Bronhaim 
>   2 Author: Sagi Shnaidman 
>   2 Author: Petr Sebek 
>   2 Author: Miguel Angel Ajo 
>   2 Author: Andrej Cernek 
>   1 Author: Viliam Serecun 
>   1 Author: Vered Volansky 
>   1 Author: Timothy Asir Jeyasingh 
>   1 Author: shlad 
>   1 Author: pkliczewski 
>   1 Author: Petr Benas 
>   1 Author: Marcin Sobczyk 
>   1 Author: Marcin Mirecki 
>   1 Author: Ilia Meerovich 
>   1 Author: Genadi Chereshnya 
>   1 Author: Dominik Holler 
>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/XL4M5WR44PKMKXYH32XIL5GEHIUFQARJ/

[ovirt-devel] Re: Pushing container to dockerhub using podman

[Edward Haas]

On Thu, Nov 14, 2019 at 10:37 PM Nir Soffer  wrote:

> On Thu, Nov 14, 2019 at 10:32 PM Edward Haas  wrote:
> >
> >
> >
> > On Thu, Nov 14, 2019 at 10:24 PM Nir Soffer  wrote:
> >>
> >> On Thu, Nov 14, 2019 at 9:29 PM Edward Haas  wrote:
> >> >
> >> > Hi All,
> >> >
> >> > I'm trying to push an image to dockerhub using podman.
> >> > Unfortunately, it does not work, giving me the following error:
> >> >
> >> > ```
> >> > $ sudo podman push 2dfe3d835f08
> ovirtorg/vdsm-test-func-network-centos-8
> >> > Getting image source signatures
> >> > Error: Error copying image to the remote destination: Error trying to
> reuse blob
> sha256:9e607bb861a7d58bece26dd2c02874beedd6a097c1b6eca5255d5eb0d2236983 at
> destination: Error checking whether a blob
> sha256:9e607bb861a7d58bece26dd2c02874beedd6a097c1b6eca5255d5eb0d2236983
> exists in docker.io/ovirtorg/vdsm-test-func-network-centos-8: errors:
> >> > denied: requested access to the resource is denied
> >> > error parsing HTTP 401 response body: unexpected end of JSON input: ""
> >> > ```
> >> > (podman login docker.io works fine)
> >> > Has anyone encounter something like this?
> >>
> >> Maybe the issue is that we have to create the repository first.
> >>
> >> I created it here:
> >>
> https://hub.docker.com/repository/docker/ovirtorg/vdsm-test-func-network-centos-8
> >>
> >> Try to push again.
> >>
> >> I think you should be able to create new repositories.
> >>
> >> Nir
> >>
> > Now I get something else:
> >
> > $ sudo podman push 2dfe3d835f08 ovirtorg/vdsm-test-func-network-centos-8
> > Getting image source signatures
> > Copying blob 55ac6f41bab4 done
> > Copying blob 140282e4f2a3 done
> > Copying blob 9f892f5760ee done
> > Copying blob 602715c702c3 done
> > Copying blob 9e607bb861a7 done
> > Error: Error copying image to the remote destination: Error writing
> blob: Error initiating layer upload to
> /v2/ovirtorg/vdsm-test-func-network-centos-8/blobs/uploads/ in
> registry-1.docker.io: errors:
> > denied: requested access to the resource is denied
> > unauthorized: authentication required
> >
>
> I found that the new repo did not have any permissions. Added
> read/write permissions here:
> https://hub.docker.com/orgs/ovirtorg/teams/vdsm/permissions
>
> Can you try again?
>
> Thanks, it worked! Huray.
___
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/ZO2AHACKU6U27KW7ZSLH6GJTV77MOWU3/

[ovirt-devel] Re: Pushing container to dockerhub using podman

[Edward Haas]

On Thu, Nov 14, 2019 at 10:34 PM Petr Horacek  wrote:

>
>
> On Thu, 14 Nov 2019, 21:33 Edward Haas,  wrote:
>
>>
>>
>> On Thu, Nov 14, 2019 at 10:24 PM Nir Soffer  wrote:
>>
>>> On Thu, Nov 14, 2019 at 9:29 PM Edward Haas  wrote:
>>> >
>>> > Hi All,
>>> >
>>> > I'm trying to push an image to dockerhub using podman.
>>> > Unfortunately, it does not work, giving me the following error:
>>> >
>>> > ```
>>> > $ sudo podman push 2dfe3d835f08
>>> ovirtorg/vdsm-test-func-network-centos-8
>>> > Getting image source signatures
>>> > Error: Error copying image to the remote destination: Error trying to
>>> reuse blob
>>> sha256:9e607bb861a7d58bece26dd2c02874beedd6a097c1b6eca5255d5eb0d2236983 at
>>> destination: Error checking whether a blob
>>> sha256:9e607bb861a7d58bece26dd2c02874beedd6a097c1b6eca5255d5eb0d2236983
>>> exists in docker.io/ovirtorg/vdsm-test-func-network-centos-8: errors:
>>> > denied: requested access to the resource is denied
>>> > error parsing HTTP 401 response body: unexpected end of JSON input: ""
>>> > ```
>>> > (podman login docker.io works fine)
>>> > Has anyone encounter something like this?
>>>
>>> Maybe the issue is that we have to create the repository first.
>>>
>>> I created it here:
>>>
>>> https://hub.docker.com/repository/docker/ovirtorg/vdsm-test-func-network-centos-8
>>>
>>> Try to push again.
>>>
>>> I think you should be able to create new repositories.
>>>
>>
No, I cannot.


>>> Nir
>>>
>>> Now I get something else:
>>
>> $ sudo podman push 2dfe3d835f08 ovirtorg/vdsm-test-func-network-centos-8
>> Getting image source signatures
>> Copying blob 55ac6f41bab4 done
>> Copying blob 140282e4f2a3 done
>> Copying blob 9f892f5760ee done
>> Copying blob 602715c702c3 done
>> Copying blob 9e607bb861a7 done
>> Error: Error copying image to the remote destination: Error writing blob:
>> Error initiating layer upload to
>> /v2/ovirtorg/vdsm-test-func-network-centos-8/blobs/uploads/ in
>> registry-1.docker.io: errors:
>> denied: requested access to the resource is denied
>> unauthorized: authentication required
>>
> docker login
>

I am logged in, I just do not have permission to ovirtorg.
I was able to push ot docker.io/ovirt/vdsm-network-functest-centos-8.


>> ___
>> 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/AU2NG5NWCTLAJQFUVMO5IBDFMIGBK7XS/
>>
>
___
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/OGWCHQEIQ5WNYZTZPJ52ELOOOYKR67S2/

[ovirt-devel] Re: Pushing container to dockerhub using podman

[Edward Haas]

On Thu, Nov 14, 2019 at 10:24 PM Nir Soffer  wrote:

> On Thu, Nov 14, 2019 at 9:29 PM Edward Haas  wrote:
> >
> > Hi All,
> >
> > I'm trying to push an image to dockerhub using podman.
> > Unfortunately, it does not work, giving me the following error:
> >
> > ```
> > $ sudo podman push 2dfe3d835f08 ovirtorg/vdsm-test-func-network-centos-8
> > Getting image source signatures
> > Error: Error copying image to the remote destination: Error trying to
> reuse blob
> sha256:9e607bb861a7d58bece26dd2c02874beedd6a097c1b6eca5255d5eb0d2236983 at
> destination: Error checking whether a blob
> sha256:9e607bb861a7d58bece26dd2c02874beedd6a097c1b6eca5255d5eb0d2236983
> exists in docker.io/ovirtorg/vdsm-test-func-network-centos-8: errors:
> > denied: requested access to the resource is denied
> > error parsing HTTP 401 response body: unexpected end of JSON input: ""
> > ```
> > (podman login docker.io works fine)
> > Has anyone encounter something like this?
>
> Maybe the issue is that we have to create the repository first.
>
> I created it here:
>
> https://hub.docker.com/repository/docker/ovirtorg/vdsm-test-func-network-centos-8
>
> Try to push again.
>
> I think you should be able to create new repositories.
>
> Nir
>
> Now I get something else:

$ sudo podman push 2dfe3d835f08 ovirtorg/vdsm-test-func-network-centos-8
Getting image source signatures
Copying blob 55ac6f41bab4 done
Copying blob 140282e4f2a3 done
Copying blob 9f892f5760ee done
Copying blob 602715c702c3 done
Copying blob 9e607bb861a7 done
Error: Error copying image to the remote destination: Error writing blob:
Error initiating layer upload to
/v2/ovirtorg/vdsm-test-func-network-centos-8/blobs/uploads/ in
registry-1.docker.io: errors:
denied: requested access to the resource is denied
unauthorized: authentication required
___
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/AU2NG5NWCTLAJQFUVMO5IBDFMIGBK7XS/

[ovirt-devel] Pushing container to dockerhub using podman

[Edward Haas]

Hi All,

I'm trying to push an image to dockerhub using podman.
Unfortunately, it does not work, giving me the following error:

```
$ sudo podman push 2dfe3d835f08 ovirtorg/vdsm-test-func-network-centos-8
Getting image source signatures
Error: Error copying image to the remote destination: Error trying to reuse
blob
sha256:9e607bb861a7d58bece26dd2c02874beedd6a097c1b6eca5255d5eb0d2236983 at
destination: Error checking whether a blob
sha256:9e607bb861a7d58bece26dd2c02874beedd6a097c1b6eca5255d5eb0d2236983
exists in docker.io/ovirtorg/vdsm-test-func-network-centos-8: errors:
denied: requested access to the resource is denied
error parsing HTTP 401 response body: unexpected end of JSON input: ""
```
(podman login docker.io works fine)
Has anyone encounter something like this?

Thanks,
Edy.
___
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/HTZJ36POUKEL7BBFSBP6BSXKW63CKRSR/

[ovirt-devel] Re: Proposing Marcin Sobczyk as VDSM infra maintainer

[Edward Haas]

On Thu, Nov 7, 2019 at 4:22 PM Milan Zamazal  wrote:

> Martin Perina  writes:
>
> > Hi,
> >
> > Marcin has joined infra team more than a year ago and during this time he
> > contributed a lot to VDSM packaging, improved automation and ported all
> > infra team parts of VDSM (jsonrpc, ssl, vdms-client, hooks infra, ...) to
> > Python 3. He is a very nice person to talk, is usually very responsive
> and
> > takes care a lot about code quality.
> >
> > So I'd like to propose Marcin as VDSM infra maintainer.
>
> +1
>

+1

>
> > Please share your thoughts.
> >
> > Thanks,
> > Martin
>
___
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/HXJEHMRLRVDXLCIABOVC45BMPJRJB2N6/

[ovirt-devel] Re: [vdsm] Standard patch check broken by Black formatter for network stuff

[Edward Haas]

https://gerrit.ovirt.org/#/c/104284/ just got merged.

On Tue, Oct 29, 2019 at 12:54 PM Tal Nisan  wrote:

> +Edward Haas  +Dominik Holler 
>
> On Tue, Oct 29, 2019 at 12:52 PM Vojtech Juranek 
> wrote:
>
>> Hi,
>> standard patch check tests for vdsm are broken due to Black formatter
>> check
>> failure (see e.g. [1]):
>>
>> Oh no!
>> 10:16:24  6 files would be reformatted, 164 files would be left unchanged.
>> 10:16:24  ERROR: InvocationError for command /home/jenkins/workspace/
>> vdsm_standard-check-patch/vdsm/.tox/black/bin/black -l 79 -S --check
>> ./lib/
>> vdsm/network/ ./tests/network (exited with code 1)
>>
>> Can someone take a look and fix it? I did a quick check and wasn't able
>> to
>> find any recent commit which should cause this failure:-(
>>
>> Thanks
>> Vojta
>>
>> [1] https://jenkins.ovirt.org/job/vdsm_standard-check-patch/13396
>> ___
>> 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/VD6LJ5A7Q3MX6TCRSWKPN6SRJJXOP55Q/
>>
>
___
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/3FEWNLBUJNGGLYJ2MF3DS5RX56DP4IJL/

[ovirt-devel] Re: Network tests fail on travis with minimal coverage not met (0%)

[Edward Haas]

On Fri, Oct 4, 2019 at 9:56 PM Nir Soffer  wrote:

> On Fri, Oct 4, 2019 at 9:44 PM Nir Soffer  wrote:
>
>> On Fri, Oct 4, 2019 at 9:32 PM Nir Soffer  wrote:
>>
>>> On Fri, Oct 4, 2019 at 8:50 PM Nir Soffer  wrote:
>>>
 Looks like wrong coverage report:

 -- coverage: platform linux2, python 2.7.16-final-0 --
 Coverage HTML written to dir htmlcov-network-py27
 FAIL Required test coverage of 38% not reached. Total coverage: 0.00%

 https://travis-ci.org/oVirt/vdsm/builds/593661358

>>>
>>> Also on jenkins:
>>> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/12604/
>>> 
>>> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/12603/
>>>
>>
>> --- coverage: platform linux, python 3.7.4-final-0 ---
>>
>> Coverage HTML written to dir htmlcov-network-py37
>>
>> FAIL Required test coverage of 42% not reached. Total coverage: 0.00%
>>
>> Looking at exported artifacts, we don't write now the coverage reports:
>>
>> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/12604/artifact/check-patch.tests-py37.fc30.x86_64/
>>
>> This will fail any vdsm patch.
>>
>>
> Looks like this issue, filed 1 hour ago:
> https://github.com/pytest-dev/pytest-cov/issues/348
>

The latest pytest-cov is broken.
I fixed the plugin version [1] and it seems to work now.

[1] https://gerrit.ovirt.org/#/c/103870/
___
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/AO7RROODDQ74XP7QNYZS3P7WNQQMDDQ5/

[ovirt-devel] Re: Dropping Fedora 28 support in oVirt development repos and jenkins

[Edward Haas]

On Thu, Jun 13, 2019 at 12:17 PM Sandro Bonazzola 
wrote:

>
>
> Il giorno gio 13 giu 2019 alle ore 11:15 Sandro Bonazzola <
> sbona...@redhat.com> ha scritto:
>
>>
>>
>> Il giorno gio 13 giu 2019 alle ore 08:34 Edward Haas 
>> ha scritto:
>>
>>>
>>>
>>> On Mon, Jun 10, 2019 at 11:00 AM Sandro Bonazzola 
>>> wrote:
>>>
>>>>
>>>>
>>>> Il giorno mer 5 giu 2019 alle ore 09:52 Sandro Bonazzola <
>>>> sbona...@redhat.com> ha scritto:
>>>>
>>>>>
>>>>>
>>>>> Il giorno mer 5 giu 2019 alle ore 09:08 Nir Soffer 
>>>>> ha scritto:
>>>>>
>>>>>> On Wed, Jun 5, 2019, 08:32 Sandro Bonazzola 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> while we are introducing support for fedora 29 and 30 we need to
>>>>>>> free resources both on jenkins and on resources.ovirt.org.
>>>>>>> Starting today I'll start pushing removal of fc28 jenkins jobs. Once
>>>>>>> done, I'm going to remove the fc28 repositories from all snapshot and
>>>>>>> tested repos, keeping fc28 repos only within the released repositories.
>>>>>>>
>>>>>>
>>>>>> This is fine once we have working f29 build.
>>>>>>
>>>>>
>>>>> Not sure we can wait that much dropping fc28.
>>>>> Right now it takes up to 3 days for a patch to land on snapshot repos
>>>>> due to the amount of time spent by deploy_to_master_tested generating the
>>>>> repositories metadata.
>>>>> And we have space limitations to the amount of builds we can keep on
>>>>> our systems.
>>>>>
>>>>
>>>> Fedora 28 jobs are being removed by jenkins right now.
>>>> If your project is not building on Fedora 29 yet (python 2 only, no
>>>> need to fix python 3 on fc29 now), please fix it as soon as possible.
>>>>
>>>
>>> VDSM jobs require the slaves to be in sync with the mock env (stdci
>>> `host-distro: same`), but the tests fail on fc29 (
>>> https://gerrit.ovirt.org/#/c/100429/).
>>> The last time we saw such failures, we performed this pinning of the
>>> version (https://gerrit.ovirt.org/#/c/96921/).
>>> Therefore, I would like to check if the slaves OS is updated compared to
>>> the mock env.
>>>
>>>
>> Yes, we have fc29 slaves: https://jenkins.ovirt.org/label/fc29/
>>
>
> Evgeny can you give a mass dnf upgrade on the fc29 slaves to ensure
> they're all updated?
>

The most important point is to upgrade the kernel, as last time it was a
user-kernel compatibility issue.


>
>>
>>
>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>> --
>>>>>>>
>>>>>>> Sandro Bonazzola
>>>>>>>
>>>>>>> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>>>>>>>
>>>>>>> Red Hat EMEA <https://www.redhat.com/>
>>>>>>>
>>>>>>> sbona...@redhat.com
>>>>>>> <https://red.ht/sig>
>>>>>>> <https://redhat.com/summit>
>>>>>>> ___
>>>>>>> Infra mailing list -- in...@ovirt.org
>>>>>>> To unsubscribe send an email to infra-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/in...@ovirt.org/message/36OHDZDMIMKCEAG3NXZWOGQGYEV2ARR2/
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Sandro Bonazzola
>>>>>
>>>>> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>>>>>
>>>>> Red Hat EMEA <https://www.redhat.com/>
>>>>>
>>>>> sbona...@redhat.com
>>>>> <https://red.ht/sig>
>>>>> <https://redhat.com/summit>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Sandro Bonazzola
>>>>
>>>> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>>>>
>>>> Red Hat EMEA <https://www.redhat.com/>
>>>>
>>>> sbona...@redhat.com
>>>> <https://red.ht/sig>
>>>> <https://redhat.com/summit>
>>>> ___
>>>> Infra mailing list -- in...@ovirt.org
>>>> To unsubscribe send an email to infra-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/in...@ovirt.org/message/HCPFUWMRZRR4VZGLY6HP5P4QDBDD3MDC/
>>>>
>>>
>>
>> --
>>
>> Sandro Bonazzola
>>
>> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>>
>> Red Hat EMEA <https://www.redhat.com/>
>>
>> sbona...@redhat.com
>> <https://www.redhat.com/>
>>
>
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>
> Red Hat EMEA <https://www.redhat.com/>
>
> sbona...@redhat.com
> <https://www.redhat.com/>
>
___
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/Y5F52GPKHIJKZLYFRAG5GJ7KFFMGX5YY/

[ovirt-devel] Re: Dropping Fedora 28 support in oVirt development repos and jenkins

[Edward Haas]

On Mon, Jun 10, 2019 at 11:00 AM Sandro Bonazzola 
wrote:

>
>
> Il giorno mer 5 giu 2019 alle ore 09:52 Sandro Bonazzola <
> sbona...@redhat.com> ha scritto:
>
>>
>>
>> Il giorno mer 5 giu 2019 alle ore 09:08 Nir Soffer 
>> ha scritto:
>>
>>> On Wed, Jun 5, 2019, 08:32 Sandro Bonazzola  wrote:
>>>
 Hi,
 while we are introducing support for fedora 29 and 30 we need to free
 resources both on jenkins and on resources.ovirt.org.
 Starting today I'll start pushing removal of fc28 jenkins jobs. Once
 done, I'm going to remove the fc28 repositories from all snapshot and
 tested repos, keeping fc28 repos only within the released repositories.

>>>
>>> This is fine once we have working f29 build.
>>>
>>
>> Not sure we can wait that much dropping fc28.
>> Right now it takes up to 3 days for a patch to land on snapshot repos due
>> to the amount of time spent by deploy_to_master_tested generating the
>> repositories metadata.
>> And we have space limitations to the amount of builds we can keep on our
>> systems.
>>
>
> Fedora 28 jobs are being removed by jenkins right now.
> If your project is not building on Fedora 29 yet (python 2 only, no need
> to fix python 3 on fc29 now), please fix it as soon as possible.
>

VDSM jobs require the slaves to be in sync with the mock env (stdci
`host-distro: same`), but the tests fail on fc29 (
https://gerrit.ovirt.org/#/c/100429/).
The last time we saw such failures, we performed this pinning of the
version (https://gerrit.ovirt.org/#/c/96921/).
Therefore, I would like to check if the slaves OS is updated compared to
the mock env.


>
>>
>>
>>
>>
>>>
>>>
 Thanks,
 --

 Sandro Bonazzola

 MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

 Red Hat EMEA 

 sbona...@redhat.com
 
 
 ___
 Infra mailing list -- in...@ovirt.org
 To unsubscribe send an email to infra-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/in...@ovirt.org/message/36OHDZDMIMKCEAG3NXZWOGQGYEV2ARR2/

>>>
>>
>> --
>>
>> Sandro Bonazzola
>>
>> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>>
>> Red Hat EMEA 
>>
>> sbona...@redhat.com
>> 
>> 
>>
>
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
> 
> ___
> Infra mailing list -- in...@ovirt.org
> To unsubscribe send an email to infra-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/in...@ovirt.org/message/HCPFUWMRZRR4VZGLY6HP5P4QDBDD3MDC/
>
___
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/KUM255POEV2BSETH55RPXEANQJJ4I37G/

[ovirt-devel] Re: repo, el7: Provide nmstate through copr for VDSM

[Edward Haas]

On Tue, Apr 30, 2019 at 12:49 PM Sandro Bonazzola 
wrote:

> Hi,
> Is https://gerrit.ovirt.org/#/c/96856/ still relevant?
> I see nmstate-0.0.5 is in EPEL testing and shipped within Fedora while the
> copr repo has 0.0.4.
> Can I abandon the patch?
>

Yes, it is relevant, especially now that nmstate is planned for RHEL 8.1.
v0.0.6 has been released last week, I think it should get into EPEL test
and we should have a copr release as well.

Please keep it for now, I will get back to it next sprint.


> --
>
> SANDRO BONAZZOLA
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
>
___
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/7T45EEAX2CNXCIQKH2D5TKIDBAWX4NXX/

[ovirt-devel] Re: [VDSM] FAIL: test_add_delete_ipv6 (network.ip_address_test.IPAddressTest) fail again

[Edward Haas]

On Tue, Jan 15, 2019 at 8:43 PM Nir Soffer  wrote:

> On Tue, Jan 15, 2019 at 8:41 PM Nir Soffer  wrote:
>
>>
>> On Tue, Jan 15, 2019 at 12:56 PM Nir Soffer  wrote:
>>
>>> On Sun, Jan 13, 2019 at 10:34 AM Edward Haas  wrote:
>>>
>>>>
>>>> Thank you Nir.
>>>> I added an assert message to this last one.
>>>> It should not happen at all, it is very strange.
>>>>
>>>> https://gerrit.ovirt.org/#/c/96849/
>>>>
>>>> Thanks,
>>>> Edy.
>>>>
>>>> On Sun, Jan 13, 2019 at 9:21 AM Nir Soffer  wrote:
>>>>
>>>>> Another network test that did not fail for long time, failed again today.
>>>>>
>>>>> Build:
>>>>>
>>>>> https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/vdsm_standard-check-patch/runs/1484/nodes/127/steps/407/log/?start=0
>>>>>
>>>>> ==
>>>>> FAIL: test_local_auto_with_static_address_without_ra_server 
>>>>> (network.netinfo_test.TestIPv6Addresses)
>>>>> --
>>>>> Traceback (most recent call last):
>>>>>   File 
>>>>> "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/testValidation.py",
>>>>>  line 333, in wrapper
>>>>> return f(*args, **kwargs)
>>>>>   File 
>>>>> "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/testValidation.py",
>>>>>  line 194, in wrapper
>>>>> return f(*args, **kwargs)
>>>>>   File 
>>>>> "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/network/netinfo_test.py",
>>>>>  line 399, in test_local_auto_with_static_address_without_ra_server
>>>>> self.assertEqual(2, len(ip_addrs))
>>>>> AssertionError: 2 != 4
>>>>>  >> begin captured logging << 
>>>>> 2019-01-13 07:08:43,598 DEBUG (MainThread) [root] /sbin/ip link add name 
>>>>> dummy_PU7TA type dummy (cwd None) (cmdutils:133)
>>>>> 2019-01-13 07:08:43,619 DEBUG (MainThread) [root] SUCCESS:  = ''; 
>>>>>  = 0 (cmdutils:141)
>>>>> 2019-01-13 07:08:43,624 DEBUG (netlink/events) [root] START thread 
>>>>>  (func=>>>> method Monitor._scan of >>>> 0x7f0817ca1610>>, args=(), kwargs={}) (concurrent:193)
>>>>> 2019-01-13 07:08:43,627 DEBUG (MainThread) [root] /sbin/ip link set dev 
>>>>> dummy_PU7TA up (cwd None) (cmdutils:133)
>>>>> 2019-01-13 07:08:43,647 DEBUG (MainThread) [root] SUCCESS:  = ''; 
>>>>>  = 0 (cmdutils:141)
>>>>> 2019-01-13 07:08:43,653 DEBUG (netlink/events) [root] FINISH thread 
>>>>>  (concurrent:196)
>>>>> 2019-01-13 07:08:43,655 DEBUG (MainThread) [root] /sbin/ip -6 addr add 
>>>>> dev dummy_PU7TA 2001::88/64 (cwd None) (cmdutils:133)
>>>>> 2019-01-13 07:08:43,669 DEBUG (MainThread) [root] SUCCESS:  = ''; 
>>>>>  = 0 (cmdutils:141)
>>>>> 2019-01-13 07:08:43,677 DEBUG (MainThread) [root] /sbin/ip link del dev 
>>>>> dummy_PU7TA (cwd None) (cmdutils:133)
>>>>> 2019-01-13 07:08:43,696 DEBUG (MainThread) [root] SUCCESS:  = ''; 
>>>>>  = 0 (cmdutils:141)
>>>>> - >> end captured logging << -
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 4, 2019 at 7:30 PM Nir Soffer  wrote:
>>>>>
>>>>>> We had this failure a lot in the past and it seems to be resolve, but
>>>>>> I see it again today:
>>>>>>
>>>>>> ==
>>>>>> FAIL: test_add_delete_ipv6 (network.ip_address_test.IPAddressTest)
>>>>>> --
>>>>>> Traceback (most recent call last):
>>>>>>   File 
>>>>>> "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/testValidation.py",
>>>>>>  line 333, in wrapper
>>>>>> return f(*args, **kwargs)
>>>>>>   File 
>>>>>> "/home/jenkins/wo

[ovirt-devel] Re: [VDSM] FAIL: test_add_delete_ipv6 (network.ip_address_test.IPAddressTest) fail again

[Edward Haas]

Thank you Nir.
I added an assert message to this last one.
It should not happen at all, it is very strange.

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

Thanks,
Edy.

On Sun, Jan 13, 2019 at 9:21 AM Nir Soffer  wrote:

> Another network test that did not fail for long time, failed again today.
>
> Build:
>
> https://jenkins.ovirt.org/blue/rest/organizations/jenkins/pipelines/vdsm_standard-check-patch/runs/1484/nodes/127/steps/407/log/?start=0
>
> ==
> FAIL: test_local_auto_with_static_address_without_ra_server 
> (network.netinfo_test.TestIPv6Addresses)
> --
> Traceback (most recent call last):
>   File 
> "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/testValidation.py",
>  line 333, in wrapper
> return f(*args, **kwargs)
>   File 
> "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/testValidation.py",
>  line 194, in wrapper
> return f(*args, **kwargs)
>   File 
> "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/network/netinfo_test.py",
>  line 399, in test_local_auto_with_static_address_without_ra_server
> self.assertEqual(2, len(ip_addrs))
> AssertionError: 2 != 4
>  >> begin captured logging << 
> 2019-01-13 07:08:43,598 DEBUG (MainThread) [root] /sbin/ip link add name 
> dummy_PU7TA type dummy (cwd None) (cmdutils:133)
> 2019-01-13 07:08:43,619 DEBUG (MainThread) [root] SUCCESS:  = '';  = 
> 0 (cmdutils:141)
> 2019-01-13 07:08:43,624 DEBUG (netlink/events) [root] START thread 
>  (func= Monitor._scan of  0x7f0817ca1610>>, args=(), kwargs={}) (concurrent:193)
> 2019-01-13 07:08:43,627 DEBUG (MainThread) [root] /sbin/ip link set dev 
> dummy_PU7TA up (cwd None) (cmdutils:133)
> 2019-01-13 07:08:43,647 DEBUG (MainThread) [root] SUCCESS:  = '';  = 
> 0 (cmdutils:141)
> 2019-01-13 07:08:43,653 DEBUG (netlink/events) [root] FINISH thread 
>  (concurrent:196)
> 2019-01-13 07:08:43,655 DEBUG (MainThread) [root] /sbin/ip -6 addr add dev 
> dummy_PU7TA 2001::88/64 (cwd None) (cmdutils:133)
> 2019-01-13 07:08:43,669 DEBUG (MainThread) [root] SUCCESS:  = '';  = 
> 0 (cmdutils:141)
> 2019-01-13 07:08:43,677 DEBUG (MainThread) [root] /sbin/ip link del dev 
> dummy_PU7TA (cwd None) (cmdutils:133)
> 2019-01-13 07:08:43,696 DEBUG (MainThread) [root] SUCCESS:  = '';  = 
> 0 (cmdutils:141)
> - >> end captured logging << -
>
>
>
> On Fri, Jan 4, 2019 at 7:30 PM Nir Soffer  wrote:
>
>> We had this failure a lot in the past and it seems to be resolve, but I
>> see it again today:
>>
>> ==
>> FAIL: test_add_delete_ipv6 (network.ip_address_test.IPAddressTest)
>> --
>> Traceback (most recent call last):
>>   File 
>> "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/testValidation.py",
>>  line 333, in wrapper
>> return f(*args, **kwargs)
>>   File 
>> "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/network/ip_address_test.py",
>>  line 226, in test_add_delete_ipv6
>> self._test_add_delete(IPV6_A_WITH_PREFIXLEN, IPV6_B_WITH_PREFIXLEN)
>>   File 
>> "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/network/ip_address_test.py",
>>  line 247, in _test_add_delete
>> self._assert_has_no_address(nic, ip_b)
>>   File 
>> "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/network/ip_address_test.py",
>>  line 344, in _assert_has_no_address
>> self._assert_address_not_in(address_with_prefixlen, addresses)
>>   File 
>> "/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/network/ip_address_test.py",
>>  line 352, in _assert_address_not_in
>> self.assertNotIn(address_with_prefixlen, addresses_list)
>> AssertionError: '2002:99::1/64' unexpectedly found in ['2002:99::1/64', 
>> '2001:99::1/64', 'fe80::6:23ff:fead:ed34/64']
>>  >> begin captured logging << 
>> 2019-01-04 16:01:53,543 DEBUG (MainThread) [root] /sbin/ip link add name 
>> dummy_NKzY1 type dummy (cwd None) (cmdutils:133)
>> 2019-01-04 16:01:53,559 DEBUG (MainThread) [root] SUCCESS:  = '';  
>> = 0 (cmdutils:141)
>> 2019-01-04 16:01:53,563 DEBUG (netlink/events) [root] START thread 
>>  (func=> Monitor._scan of > 0x7f271d654cd0>>, args=(), kwargs={}) (concurrent:193)
>> 2019-01-04 16:01:53,567 DEBUG (MainThread) [root] /sbin/ip link set dev 
>> dummy_NKzY1 up (cwd None) (cmdutils:133)
>> 2019-01-04 16:01:53,586 DEBUG (MainThread) [root] SUCCESS:  = '';  
>> = 0 (cmdutils:141)
>> 2019-01-04 16:01:53,593 DEBUG (netlink/events) [root] FINISH thread 
>>  (concurrent:196)
>> 2019-01-04 16:01:53,597 DEBUG (MainThread) [root] /sbin/ip -6 addr add dev 
>> dummy_NKzY1 2001:99::1/64 (cwd None) (cmdutils:133)
>> 2019-01-04 16:01:53,615 DEBUG (MainThread) [root] SUCCESS:  = '';  
>

[ovirt-devel] Re: [VDSM] all test passed, build failed with "tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we read it"

[Edward Haas]

On Mon, Dec 17, 2018 at 8:39 AM Barak Korren  wrote:

>
>
> On Mon, 17 Dec 2018 at 08:32, Edward Haas  wrote:
>
>>
>>
>> On Sun, Dec 16, 2018 at 3:31 PM Barak Korren  wrote:
>>
>>>
>>>
>>> On Sun, 16 Dec 2018 at 14:44, Edward Haas  wrote:
>>>
>>>>
>>>>
>>>> On Sun, Dec 16, 2018 at 2:40 PM Nir Soffer  wrote:
>>>>
>>>>> On Sun, Dec 16, 2018 at 2:21 PM Nir Soffer  wrote:
>>>>>
>>>>>> On Sun, Dec 2, 2018 at 8:18 AM Edward Haas 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Dec 1, 2018 at 11:10 PM Nir Soffer 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Thu, Nov 29, 2018 at 11:21 AM Edward Haas 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Nov 29, 2018 at 10:41 AM Edward Haas 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 28, 2018 at 8:12 PM Nir Soffer 
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> We have this failure that pops randomly:
>>>>>>>>>>>
>>>>>>>>>>> 1. All tests pass
>>>>>>>>>>>
>>>>>>>>>>> *00:13:13.284* ___ summary 
>>>>>>>>>>> *00:13:13.285*   tests: 
>>>>>>>>>>> commands succeeded*00:13:13.286*   storage-py27: commands 
>>>>>>>>>>> succeeded*00:13:13.286*   storage-py36: commands 
>>>>>>>>>>> succeeded*00:13:13.286*   lib-py27: commands 
>>>>>>>>>>> succeeded*00:13:13.287*   lib-py36: commands 
>>>>>>>>>>> succeeded*00:13:13.288*   network-py27: commands 
>>>>>>>>>>> succeeded*00:13:13.290*   network-py36: commands 
>>>>>>>>>>> succeeded*00:13:13.291*   virt-py27: commands 
>>>>>>>>>>> succeeded*00:13:13.292*   virt-py36: commands 
>>>>>>>>>>> succeeded*00:13:13.293*   congratulations :)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2. But we fail to collect logs at the end
>>>>>>>>>>>
>>>>>>>>>>> *00:14:35.992* 
>>>>>>>>>>> ##*00:14:35.995*
>>>>>>>>>>>  ## Wed Nov 28 17:39:50 UTC 2018 Finished env: 
>>>>>>>>>>> fc28:fedora-28-x86_64*00:14:35.996* ##  took 764 
>>>>>>>>>>> seconds*00:14:35.997* ##  rc = 1*00:14:35.997* 
>>>>>>>>>>> ##*00:14:36.009*
>>>>>>>>>>>  ##! ERROR v*00:14:36.010* 
>>>>>>>>>>> ##! Last 20 log entries: 
>>>>>>>>>>> /tmp/mock_logs.Lcop4ZOq/script/stdout_stderr.log*00:14:36.011* 
>>>>>>>>>>> ##!*00:14:36.012* 
>>>>>>>>>>> journal/b087148aba6d49b9bbef488e52a48752/system.journal*00:14:36.013*
>>>>>>>>>>>  tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file 
>>>>>>>>>>> changed as we read it*00:14:36.014* 
>>>>>>>>>>> journal/b087148aba6d49b9bbef488e52a48752/user-1000.journal*00:14:36.015*
>>>>>>>>>>>  lastlog*00:14:36.015* libvirt/*00:14:36.015* 
>>>>>>>>>>> libvirt/lxc/*00:14:36.015* libvirt/libxl/*00:14:36.016* 
>>>>>>>>>>> libvirt/qemu/*00:14:36.016* 
>>>>>>>>>>> libvirt/qemu/LiveOS-f920001d-be4e-47ea-ac26-72480fd5be87.log*00:14:36.017*
>>>>>>>>>>>  libvirt/uml/*00:14:36.017* ovirt-guest-agent/*00:14:36.017* 
>>>>>>>>>>> ovirt-guest-agent/ovirt-guest-agent.log*00:14:36.017* 
>>>>&

[ovirt-devel] Re: [VDSM] all test passed, build failed with "tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we read it"

[Edward Haas]

On Sun, Dec 16, 2018 at 3:31 PM Barak Korren  wrote:

>
>
> On Sun, 16 Dec 2018 at 14:44, Edward Haas  wrote:
>
>>
>>
>> On Sun, Dec 16, 2018 at 2:40 PM Nir Soffer  wrote:
>>
>>> On Sun, Dec 16, 2018 at 2:21 PM Nir Soffer  wrote:
>>>
>>>> On Sun, Dec 2, 2018 at 8:18 AM Edward Haas  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, Dec 1, 2018 at 11:10 PM Nir Soffer  wrote:
>>>>>
>>>>>> On Thu, Nov 29, 2018 at 11:21 AM Edward Haas 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 29, 2018 at 10:41 AM Edward Haas 
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Nov 28, 2018 at 8:12 PM Nir Soffer 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> We have this failure that pops randomly:
>>>>>>>>>
>>>>>>>>> 1. All tests pass
>>>>>>>>>
>>>>>>>>> *00:13:13.284* ___ summary 
>>>>>>>>> *00:13:13.285*   tests: commands 
>>>>>>>>> succeeded*00:13:13.286*   storage-py27: commands 
>>>>>>>>> succeeded*00:13:13.286*   storage-py36: commands 
>>>>>>>>> succeeded*00:13:13.286*   lib-py27: commands succeeded*00:13:13.287*  
>>>>>>>>>  lib-py36: commands succeeded*00:13:13.288*   network-py27: commands 
>>>>>>>>> succeeded*00:13:13.290*   network-py36: commands 
>>>>>>>>> succeeded*00:13:13.291*   virt-py27: commands succeeded*00:13:13.292* 
>>>>>>>>>   virt-py36: commands succeeded*00:13:13.293*   congratulations :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2. But we fail to collect logs at the end
>>>>>>>>>
>>>>>>>>> *00:14:35.992* 
>>>>>>>>> ##*00:14:35.995*
>>>>>>>>>  ## Wed Nov 28 17:39:50 UTC 2018 Finished env: 
>>>>>>>>> fc28:fedora-28-x86_64*00:14:35.996* ##  took 764 
>>>>>>>>> seconds*00:14:35.997* ##  rc = 1*00:14:35.997* 
>>>>>>>>> ##*00:14:36.009*
>>>>>>>>>  ##! ERROR v*00:14:36.010* 
>>>>>>>>> ##! Last 20 log entries: 
>>>>>>>>> /tmp/mock_logs.Lcop4ZOq/script/stdout_stderr.log*00:14:36.011* 
>>>>>>>>> ##!*00:14:36.012* 
>>>>>>>>> journal/b087148aba6d49b9bbef488e52a48752/system.journal*00:14:36.013* 
>>>>>>>>> tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file 
>>>>>>>>> changed as we read it*00:14:36.014* 
>>>>>>>>> journal/b087148aba6d49b9bbef488e52a48752/user-1000.journal*00:14:36.015*
>>>>>>>>>  lastlog*00:14:36.015* libvirt/*00:14:36.015* 
>>>>>>>>> libvirt/lxc/*00:14:36.015* libvirt/libxl/*00:14:36.016* 
>>>>>>>>> libvirt/qemu/*00:14:36.016* 
>>>>>>>>> libvirt/qemu/LiveOS-f920001d-be4e-47ea-ac26-72480fd5be87.log*00:14:36.017*
>>>>>>>>>  libvirt/uml/*00:14:36.017* ovirt-guest-agent/*00:14:36.017* 
>>>>>>>>> ovirt-guest-agent/ovirt-guest-agent.log*00:14:36.017* 
>>>>>>>>> README*00:14:36.018* samba/*00:14:36.018* samba/old/*00:14:36.018* 
>>>>>>>>> sssd/*00:14:36.018* tallylog*00:14:36.018* wtmp*00:14:36.018* Took 
>>>>>>>>> 678 seconds*00:14:36.018* 
>>>>>>>>> ===*00:14:36.019* ##!*00:14:36.019* 
>>>>>>>>> ##! ERROR ^^*00:14:36.019* 
>>>>>>>>> ##!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This looks like an issue with vdsm check-patch.sh:
>>>>>>>>>
>>>>>>>>> function collect_logs {
>&

[ovirt-devel] Re: [VDSM] all test passed, build failed with "tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we read it"

[Edward Haas]

On Sun, Dec 16, 2018 at 2:40 PM Nir Soffer  wrote:

> On Sun, Dec 16, 2018 at 2:21 PM Nir Soffer  wrote:
>
>> On Sun, Dec 2, 2018 at 8:18 AM Edward Haas  wrote:
>>
>>>
>>>
>>> On Sat, Dec 1, 2018 at 11:10 PM Nir Soffer  wrote:
>>>
>>>> On Thu, Nov 29, 2018 at 11:21 AM Edward Haas 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 29, 2018 at 10:41 AM Edward Haas 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Nov 28, 2018 at 8:12 PM Nir Soffer 
>>>>>> wrote:
>>>>>>
>>>>>>> We have this failure that pops randomly:
>>>>>>>
>>>>>>> 1. All tests pass
>>>>>>>
>>>>>>> *00:13:13.284* ___ summary 
>>>>>>> *00:13:13.285*   tests: commands 
>>>>>>> succeeded*00:13:13.286*   storage-py27: commands 
>>>>>>> succeeded*00:13:13.286*   storage-py36: commands 
>>>>>>> succeeded*00:13:13.286*   lib-py27: commands succeeded*00:13:13.287*   
>>>>>>> lib-py36: commands succeeded*00:13:13.288*   network-py27: commands 
>>>>>>> succeeded*00:13:13.290*   network-py36: commands 
>>>>>>> succeeded*00:13:13.291*   virt-py27: commands succeeded*00:13:13.292*   
>>>>>>> virt-py36: commands succeeded*00:13:13.293*   congratulations :)
>>>>>>>
>>>>>>>
>>>>>>> 2. But we fail to collect logs at the end
>>>>>>>
>>>>>>> *00:14:35.992* 
>>>>>>> ##*00:14:35.995*
>>>>>>>  ## Wed Nov 28 17:39:50 UTC 2018 Finished env: 
>>>>>>> fc28:fedora-28-x86_64*00:14:35.996* ##  took 764 
>>>>>>> seconds*00:14:35.997* ##  rc = 1*00:14:35.997* 
>>>>>>> ##*00:14:36.009*
>>>>>>>  ##! ERROR v*00:14:36.010* ##! 
>>>>>>> Last 20 log entries: 
>>>>>>> /tmp/mock_logs.Lcop4ZOq/script/stdout_stderr.log*00:14:36.011* 
>>>>>>> ##!*00:14:36.012* 
>>>>>>> journal/b087148aba6d49b9bbef488e52a48752/system.journal*00:14:36.013* 
>>>>>>> tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file 
>>>>>>> changed as we read it*00:14:36.014* 
>>>>>>> journal/b087148aba6d49b9bbef488e52a48752/user-1000.journal*00:14:36.015*
>>>>>>>  lastlog*00:14:36.015* libvirt/*00:14:36.015* 
>>>>>>> libvirt/lxc/*00:14:36.015* libvirt/libxl/*00:14:36.016* 
>>>>>>> libvirt/qemu/*00:14:36.016* 
>>>>>>> libvirt/qemu/LiveOS-f920001d-be4e-47ea-ac26-72480fd5be87.log*00:14:36.017*
>>>>>>>  libvirt/uml/*00:14:36.017* ovirt-guest-agent/*00:14:36.017* 
>>>>>>> ovirt-guest-agent/ovirt-guest-agent.log*00:14:36.017* 
>>>>>>> README*00:14:36.018* samba/*00:14:36.018* samba/old/*00:14:36.018* 
>>>>>>> sssd/*00:14:36.018* tallylog*00:14:36.018* wtmp*00:14:36.018* Took 678 
>>>>>>> seconds*00:14:36.018* ===*00:14:36.019* 
>>>>>>> ##!*00:14:36.019* ##! ERROR 
>>>>>>> ^^*00:14:36.019* 
>>>>>>> ##!
>>>>>>>
>>>>>>>
>>>>>>> This looks like an issue with vdsm check-patch.sh:
>>>>>>>
>>>>>>> function collect_logs {
>>>>>>> res=$?
>>>>>>> [ "$res" -ne 0 ] && echo "*** err: $res"
>>>>>>> cd /var/log
>>>>>>> tar -cvzf "$EXPORT_DIR/mock_varlogs.tar.gz" *
>>>>>>> cd /var/host_log
>>>>>>> tar -cvzf "$EXPORT_DIR/host_varlogs.tar.gz" *
>>>>>>> }
>>>>>>>
>>>>>>> trap collect_logs EXIT
>>>>>>>
>>>>>>> Seems that tar fail to collect log if the log is modified while
>>>>>>> copied, which makes sense.
>>>

[ovirt-devel] Re: Announcing 'COVERAGE' option in OST

[Edward Haas]

Thank you Marcin, this is very nice.

Thanks,
Edy.

On Wed, Dec 12, 2018 at 9:59 PM Nir Soffer  wrote:

> On Wed, Dec 12, 2018 at 3:42 PM Marcin Sobczyk 
> wrote:
>
>> Hi,
>>
>> I've been working on adding coverage report for VDSM in OST
>> recently, and I'm happy to announce, that the first batch of patches is
>> merged!
>>
>> To run a suite with coverage, look for 'COVERAGE' drop-down on OST's
>> build parameters page. If you run OST locally, pass a '--coverage'
>> argument to 'run_suite.sh'.
>>
>> Currently, coverage works only for VDSM in basic-suite-master, but adding
>> VDSM support for other suites is now a no-brainer. More patches are on
>> the way!
>>
>> Since the option is named 'COVERAGE', and not 'VDSM_COVERAGE', other
>> projects
>> are welcome to implement their coverage reports on top of it.
>>
>> Cheers, Marcin
>>
>
> Awesome, thanks for the update!
>
> Nir
>
___
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/ULSXRX4QJJHGPT6HHO24PJLPTRON7TF3/

[ovirt-devel] Re: [VDSM] all test passed, build failed with "tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we read it"

[Edward Haas]

On Sat, Dec 1, 2018 at 11:10 PM Nir Soffer  wrote:

> On Thu, Nov 29, 2018 at 11:21 AM Edward Haas  wrote:
>
>>
>>
>> On Thu, Nov 29, 2018 at 10:41 AM Edward Haas  wrote:
>>
>>>
>>>
>>> On Wed, Nov 28, 2018 at 8:12 PM Nir Soffer  wrote:
>>>
>>>> We have this failure that pops randomly:
>>>>
>>>> 1. All tests pass
>>>>
>>>> *00:13:13.284* ___ summary 
>>>> *00:13:13.285*   tests: commands 
>>>> succeeded*00:13:13.286*   storage-py27: commands succeeded*00:13:13.286*   
>>>> storage-py36: commands succeeded*00:13:13.286*   lib-py27: commands 
>>>> succeeded*00:13:13.287*   lib-py36: commands succeeded*00:13:13.288*   
>>>> network-py27: commands succeeded*00:13:13.290*   network-py36: commands 
>>>> succeeded*00:13:13.291*   virt-py27: commands succeeded*00:13:13.292*   
>>>> virt-py36: commands succeeded*00:13:13.293*   congratulations :)
>>>>
>>>>
>>>> 2. But we fail to collect logs at the end
>>>>
>>>> *00:14:35.992* 
>>>> ##*00:14:35.995* 
>>>> ## Wed Nov 28 17:39:50 UTC 2018 Finished env: 
>>>> fc28:fedora-28-x86_64*00:14:35.996* ##  took 764 seconds*00:14:35.997* 
>>>> ##  rc = 1*00:14:35.997* 
>>>> ##*00:14:36.009* 
>>>> ##! ERROR v*00:14:36.010* ##! Last 
>>>> 20 log entries: 
>>>> /tmp/mock_logs.Lcop4ZOq/script/stdout_stderr.log*00:14:36.011* 
>>>> ##!*00:14:36.012* 
>>>> journal/b087148aba6d49b9bbef488e52a48752/system.journal*00:14:36.013* tar: 
>>>> journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as 
>>>> we read it*00:14:36.014* 
>>>> journal/b087148aba6d49b9bbef488e52a48752/user-1000.journal*00:14:36.015* 
>>>> lastlog*00:14:36.015* libvirt/*00:14:36.015* libvirt/lxc/*00:14:36.015* 
>>>> libvirt/libxl/*00:14:36.016* libvirt/qemu/*00:14:36.016* 
>>>> libvirt/qemu/LiveOS-f920001d-be4e-47ea-ac26-72480fd5be87.log*00:14:36.017* 
>>>> libvirt/uml/*00:14:36.017* ovirt-guest-agent/*00:14:36.017* 
>>>> ovirt-guest-agent/ovirt-guest-agent.log*00:14:36.017* README*00:14:36.018* 
>>>> samba/*00:14:36.018* samba/old/*00:14:36.018* sssd/*00:14:36.018* 
>>>> tallylog*00:14:36.018* wtmp*00:14:36.018* Took 678 seconds*00:14:36.018* 
>>>> ===*00:14:36.019* ##!*00:14:36.019* ##! 
>>>> ERROR ^^*00:14:36.019* 
>>>> ##!
>>>>
>>>>
>>>> This looks like an issue with vdsm check-patch.sh:
>>>>
>>>> function collect_logs {
>>>> res=$?
>>>> [ "$res" -ne 0 ] && echo "*** err: $res"
>>>> cd /var/log
>>>> tar -cvzf "$EXPORT_DIR/mock_varlogs.tar.gz" *
>>>> cd /var/host_log
>>>> tar -cvzf "$EXPORT_DIR/host_varlogs.tar.gz" *
>>>> }
>>>>
>>>> trap collect_logs EXIT
>>>>
>>>> Seems that tar fail to collect log if the log is modified while copied,
>>>> which makes sense.
>>>>
>>>> We can ignore errors in tar, since log collection should not fail the
>>>> build, but I think
>>>> a better solution is to avoid collecting any logs since vdsm writes its
>>>> own logs during
>>>> tests - all the info must be in vdsm log.
>>>>
>>>> Here is the list of collected logs:
>>>>
>>>> *00:13:47.280* + tar -cvzf 
>>>> /home/jenkins/workspace/vdsm_master_check-patch-fc28-x86_64/vdsm/exported-artifacts/mock_varlogs.tar.gz
>>>>  btmp dnf.librepo.log dnf.log dnf.rpm.log faillog glusterfs hawkey.log 
>>>> journal lastlog libvirt openvswitch README tallylog vdsm_tests.log wtmp 
>>>> yum.log*00:13:47.285* btmp*00:13:47.285* dnf.librepo.log*00:13:47.299* 
>>>> dnf.log*00:13:47.309* dnf.rpm.log*00:13:47.310* faillog*00:13:47.311* 
>>>> glusterfs/*00:13:47.312* hawkey.log*00:13:47.313* journal/*00:13:47.313* 
>>>> lastlog*00:13:47.315* libvirt/*00:13:47.315* libvirt/qemu/*00:13:47.316* 
>>>> openvswitch/*00:13:47.317* openvswitch/ovs-vswitchd.log*00:13:47.318* 
>&

[ovirt-devel] Re: [VDSM] all test passed, build failed with "tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we read it"

[Edward Haas]

On Thu, Nov 29, 2018 at 10:41 AM Edward Haas  wrote:

>
>
> On Wed, Nov 28, 2018 at 8:12 PM Nir Soffer  wrote:
>
>> We have this failure that pops randomly:
>>
>> 1. All tests pass
>>
>> *00:13:13.284* ___ summary 
>> *00:13:13.285*   tests: commands 
>> succeeded*00:13:13.286*   storage-py27: commands succeeded*00:13:13.286*   
>> storage-py36: commands succeeded*00:13:13.286*   lib-py27: commands 
>> succeeded*00:13:13.287*   lib-py36: commands succeeded*00:13:13.288*   
>> network-py27: commands succeeded*00:13:13.290*   network-py36: commands 
>> succeeded*00:13:13.291*   virt-py27: commands succeeded*00:13:13.292*   
>> virt-py36: commands succeeded*00:13:13.293*   congratulations :)
>>
>>
>> 2. But we fail to collect logs at the end
>>
>> *00:14:35.992* 
>> ##*00:14:35.995* ## 
>> Wed Nov 28 17:39:50 UTC 2018 Finished env: 
>> fc28:fedora-28-x86_64*00:14:35.996* ##  took 764 seconds*00:14:35.997* 
>> ##  rc = 1*00:14:35.997* 
>> ##*00:14:36.009* ##! 
>> ERROR v*00:14:36.010* ##! Last 20 
>> log entries: /tmp/mock_logs.Lcop4ZOq/script/stdout_stderr.log*00:14:36.011* 
>> ##!*00:14:36.012* 
>> journal/b087148aba6d49b9bbef488e52a48752/system.journal*00:14:36.013* tar: 
>> journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we 
>> read it*00:14:36.014* 
>> journal/b087148aba6d49b9bbef488e52a48752/user-1000.journal*00:14:36.015* 
>> lastlog*00:14:36.015* libvirt/*00:14:36.015* libvirt/lxc/*00:14:36.015* 
>> libvirt/libxl/*00:14:36.016* libvirt/qemu/*00:14:36.016* 
>> libvirt/qemu/LiveOS-f920001d-be4e-47ea-ac26-72480fd5be87.log*00:14:36.017* 
>> libvirt/uml/*00:14:36.017* ovirt-guest-agent/*00:14:36.017* 
>> ovirt-guest-agent/ovirt-guest-agent.log*00:14:36.017* README*00:14:36.018* 
>> samba/*00:14:36.018* samba/old/*00:14:36.018* sssd/*00:14:36.018* 
>> tallylog*00:14:36.018* wtmp*00:14:36.018* Took 678 seconds*00:14:36.018* 
>> ===*00:14:36.019* ##!*00:14:36.019* ##! 
>> ERROR ^^*00:14:36.019* 
>> ##!
>>
>>
>> This looks like an issue with vdsm check-patch.sh:
>>
>> function collect_logs {
>> res=$?
>> [ "$res" -ne 0 ] && echo "*** err: $res"
>> cd /var/log
>> tar -cvzf "$EXPORT_DIR/mock_varlogs.tar.gz" *
>> cd /var/host_log
>> tar -cvzf "$EXPORT_DIR/host_varlogs.tar.gz" *
>> }
>>
>> trap collect_logs EXIT
>>
>> Seems that tar fail to collect log if the log is modified while copied,
>> which makes sense.
>>
>> We can ignore errors in tar, since log collection should not fail the
>> build, but I think
>> a better solution is to avoid collecting any logs since vdsm writes its
>> own logs during
>> tests - all the info must be in vdsm log.
>>
>> Here is the list of collected logs:
>>
>> *00:13:47.280* + tar -cvzf 
>> /home/jenkins/workspace/vdsm_master_check-patch-fc28-x86_64/vdsm/exported-artifacts/mock_varlogs.tar.gz
>>  btmp dnf.librepo.log dnf.log dnf.rpm.log faillog glusterfs hawkey.log 
>> journal lastlog libvirt openvswitch README tallylog vdsm_tests.log wtmp 
>> yum.log*00:13:47.285* btmp*00:13:47.285* dnf.librepo.log*00:13:47.299* 
>> dnf.log*00:13:47.309* dnf.rpm.log*00:13:47.310* faillog*00:13:47.311* 
>> glusterfs/*00:13:47.312* hawkey.log*00:13:47.313* journal/*00:13:47.313* 
>> lastlog*00:13:47.315* libvirt/*00:13:47.315* libvirt/qemu/*00:13:47.316* 
>> openvswitch/*00:13:47.317* openvswitch/ovs-vswitchd.log*00:13:47.318* 
>> openvswitch/ovsdb-server.log*00:13:47.319* README*00:13:47.320* 
>> tallylog*00:13:47.321* vdsm_tests.log*00:13:47.342* wtmp*00:13:47.343* 
>> yum.log*00:13:47.349* + cd /var/host_log*00:13:47.350* + tar -cvzf 
>> /home/jenkins/workspace/vdsm_master_check-patch-fc28-x86_64/vdsm/exported-artifacts/host_varlogs.tar.gz
>>  anaconda audit boot.log btmp chrony cloud-init.log cloud-init-output.log 
>> cron dnf.librepo.log dnf.log dnf.rpm.log firewalld glusterfs hawkey.log 
>> journal lastlog libvirt ovirt-guest-agent README samba sssd tallylog 
>> wtmp*00:13:47.356* anaconda/*00:13:47.356* anaconda/ifcfg.log*00:13:47.357* 
>> anaconda/ks-script-l5qnynnj.log*00:13:47.358* 
>> anaconda/storage.log*00:13:47.359* anaconda/program.log

[ovirt-devel] Re: [VDSM] all test passed, build failed with "tar: journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we read it"

[Edward Haas]

t-slrcz39_.log*00:13:47.503* audit/*00:13:47.504* 
> audit/audit.log.3*00:13:47.657* audit/audit.log.2*00:13:47.814* 
> audit/audit.log.1*00:13:47.981* audit/audit.log*00:13:48.008* 
> audit/audit.log.4*00:13:48.155* boot.log*00:13:48.156* btmp*00:13:48.157* 
> chrony/*00:13:48.159* cloud-init.log*00:13:48.159* 
> cloud-init-output.log*00:13:48.161* cron*00:13:48.162* 
> dnf.librepo.log*00:13:49.930* dnf.log*00:13:51.335* dnf.rpm.log*00:13:51.421* 
> firewalld*00:13:51.423* glusterfs/*00:13:51.424* hawkey.log*00:13:51.704* 
> journal/*00:13:51.708* 
> journal/b087148aba6d49b9bbef488e52a48752/*00:13:51.709* 
> journal/b087148aba6d49b9bbef488e52a48752/system.journal*00:13:55.817* tar: 
> journal/b087148aba6d49b9bbef488e52a48752/system.journal: file changed as we 
> read it*00:13:55.819* 
> journal/b087148aba6d49b9bbef488e52a48752/user-1000.journal*00:13:55.915* 
> lastlog*00:13:55.923* libvirt/*00:13:55.924* libvirt/lxc/*00:13:55.926* 
> libvirt/libxl/*00:13:55.927* libvirt/qemu/*00:13:55.928* 
> libvirt/qemu/LiveOS-f920001d-be4e-47ea-ac26-72480fd5be87.log*00:13:55.929* 
> libvirt/uml/*00:13:55.930* ovirt-guest-agent/*00:13:55.930* 
> ovirt-guest-agent/ovirt-guest-agent.log*00:13:55.932* README*00:13:55.933* 
> samba/*00:13:55.933* samba/old/*00:13:55.935* sssd/*00:13:55.935* 
> tallylog*00:13:55.935* wtmp
>
>
> Most if not all are lot relevant to vdsm tests, and should not be
> collected.
>
> This was added in:
>
> commit 9c9c17297433e5a5a49aa19cde10b206e7db61e9
> Author: Edward Haas 
> Date:   Tue Apr 17 10:53:11 2018 +0300
>
> automation: Collect logs even when check-patch fails
>
> Change-Id: Idfe07ce6fc55473b1db1d7f16754f559cc5c345a
> Signed-off-by: Edward Haas 
>
> Reviewed in:
> https://gerrit.ovirt.org/c/90370
>
> Edward, can you explain why do we need to collect logs during check-patch,
> and why do we need to collect all the logs in the system?
>

check-patch are running unit and integrations tests.
The integration tests are touching the OS and other packages (like
openvswitch).
It was added so we can debug why tests failed.

I guess we can now separate the unit and integration tests, but it will not
solve
the problem presented here.
Failing to collect the logs silently sounds a good enough solution to me.


>
> Nir
>
___
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/NH2IBZIPUDIU5W3EIES5TZCSPMDU74VS/

[ovirt-devel] Re: [VDSM] check-merged failing for years - remove it?

[Edward Haas]

On Wed, Nov 28, 2018 at 11:28 AM Marcin Sobczyk  wrote:

> How much value does it add comparing to check-patch?
>
> If we can hold for a while with pulling the plug, I can try to split it
> into substages in stdci v2 and see if things stabilize a bit.
>

I would prefer we first work with stdci v2 in order to move the functional
tests there (or at least play with it).
Then we can remove it.


> Marcin
> On 11/28/18 5:48 AM, Dan Kenigsberg wrote:
>
>
>
> On Tue, 27 Nov 2018, 22:49 Nir Soffer 
>> vdsm check-merged job takes 1.5 hours, and fails 80% of the time.
>>
>> https://jenkins.ovirt.org/job/vdsm_master_check-merged-el7-x86_64/buildTimeTrend
>>
>> Nobody checks these failures or care about them. We are abusing CI
>> resources for
>> no benefit.
>>
>> Can we remove this job?
>>
>
> I fought for it quite a lot, but now is the time for me to declare defeat.
>
> Unless someone here volunteers to maintain it, we should put the plug out.
>
>
>> Nir
>>
>>
___
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/AHIXVC2C4VQQEQVVENMUGB2SSMNKA2GK/

[ovirt-devel] Re: VDSM API schema inconsistencies

[Edward Haas]

On Mon, Oct 15, 2018 at 2:24 PM Marcin Sobczyk  wrote:

>
> On 10/10/18 12:53 PM, Marcin Sobczyk wrote:
>
>
> On 10/10/18 9:57 AM, Edward Haas wrote:
>
>
>
> On Mon, Oct 8, 2018 at 3:41 PM Marcin Sobczyk  wrote:
>
>> Hi,
>>
>> when I was working on BZ#1624306 it turned out, that even if I'd fix the
>> help-printing code in vdsm-client, there's still a lot of inconsistencies
>> in API's schema files.
>>
>> After some investigation, I found that there's a code for reporting
>> schema inconsistencies, but it's turned off because it bloats the logs.
>> There's also a "strict" mode that raises an exception each time an
>> inconsistency is found, but it's also off because there's so many of them.
>>
>> I think that no one wants to maintain both: the actual code and schema
>> files. My idea would be to make the schema derived from the code at build
>> time as a long-term effort. Before we can do that though, we need to
>> address the inconsistencies first.
>>
> The schema is supposed to be the specification and the code its
> implementation. Generating the schema from the code does not sound right to
> me.
>
>>
>> https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:vdsm-api-schema-debug
>>
>> This is a series of patches that helps fixing schema issues. What it
>> does, is it adds a bunch of information from stack to vastly ease the
>> process of fixing them. The logging level is also changed from 'WARNING' to
>> 'DEBUG'. Here's an example of a logged entry:
>>
>> Host.setKsmTune
>> With message: Required property pages_to_scan is not provided when
>> calling Host.setKsmTune
>> With backtrace: [
>> [
>> "_verify_object_type",
>> {
>> "call_arg_keys":[
>> "merge_across_nodes",
>> "run"
>> ],
>> "schema_type_name":"KsmTuneParams"
>> }
>> ],
>> [
>> "_verify_complex_type",
>> {
>> "schema_type_type":"object"
>> }
>> ]
>> ]
>>
>> To make it work, a patch for OST's 'basic-master-suite' is on the way
>> that switches 'schema.inconsistency' logger's logging level do 'DEBUG'.
>> That way, we can find all reported errors in 'vdsm-schema-error.log' files.
>>
> Will we be able to detect the caller?
>
> I will look at it.
>
>
> I can include the context string in the log. Example entries:
> With context string: from=:::10.37.128.217,49550, flow_id=22456882
> With context string: from=::1,51550
>
> AFAIK you can trace back the caller by the 'flow_id'. Would that kind of
> information suffice?
>
The address is enough for me. Now sure how the flow_id helps (I would not
know how to use it).
Thanks.

>
> An initial report that groups reported errors by namespaces/methods has
>> also been made. Please note, that an implementation that completely avoids
>> error duplicates is really hard and IMHO not worth the effort. You can find
>> the results here:
>>
>>- Host: https://pastebin.com/YM2XnvTV
>>
>> We will need to cover the network stuff in here, thanks.
>
>>
>>- Image: https://pastebin.com/GRc1yErL
>>- LVMVolumeGroup: https://pastebin.com/R1276gTu
>>- SDM: https://pastebin.com/P3tfYEDD
>>- StorageDomain: https://pastebin.com/Q0DxKgF5
>>- StoragePool: https://pastebin.com/VXFWpfRC
>>- VM: https://pastebin.com/tDC60c29
>>- Volume: https://pastebin.com/TYkr9Zsd
>>- |jobs|: https://pastebin.com/jeXpYyz9
>>- |virt|: https://pastebin.com/nRREuEub
>>
>> Regards, Marcin
>> ___
>> 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/NW67DZSIMQTFB4HG6SDCACFFOY6CB2YN/
>>
>
___
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/M3VABW47DQL2EBYVU7VWIQSSJ2UZUJMY/

[ovirt-devel] Re: VDSM API schema inconsistencies

[Edward Haas]

On Mon, Oct 8, 2018 at 3:41 PM Marcin Sobczyk  wrote:

> Hi,
>
> when I was working on BZ#1624306 it turned out, that even if I'd fix the
> help-printing code in vdsm-client, there's still a lot of inconsistencies
> in API's schema files.
>
> After some investigation, I found that there's a code for reporting schema
> inconsistencies, but it's turned off because it bloats the logs. There's
> also a "strict" mode that raises an exception each time an inconsistency is
> found, but it's also off because there's so many of them.
>
> I think that no one wants to maintain both: the actual code and schema
> files. My idea would be to make the schema derived from the code at build
> time as a long-term effort. Before we can do that though, we need to
> address the inconsistencies first.
>
The schema is supposed to be the specification and the code its
implementation. Generating the schema from the code does not sound right to
me.

>
> https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:vdsm-api-schema-debug
>
> This is a series of patches that helps fixing schema issues. What it does,
> is it adds a bunch of information from stack to vastly ease the process of
> fixing them. The logging level is also changed from 'WARNING' to 'DEBUG'.
> Here's an example of a logged entry:
>
> Host.setKsmTune
> With message: Required property pages_to_scan is not provided when calling
> Host.setKsmTune
> With backtrace: [
> [
> "_verify_object_type",
> {
> "call_arg_keys":[
> "merge_across_nodes",
> "run"
> ],
> "schema_type_name":"KsmTuneParams"
> }
> ],
> [
> "_verify_complex_type",
> {
> "schema_type_type":"object"
> }
> ]
> ]
>
> To make it work, a patch for OST's 'basic-master-suite' is on the way that
> switches 'schema.inconsistency' logger's logging level do 'DEBUG'. That
> way, we can find all reported errors in 'vdsm-schema-error.log' files.
>
Will we be able to detect the caller?

> An initial report that groups reported errors by namespaces/methods has
> also been made. Please note, that an implementation that completely avoids
> error duplicates is really hard and IMHO not worth the effort. You can find
> the results here:
>
>- Host: https://pastebin.com/YM2XnvTV
>
> We will need to cover the network stuff in here, thanks.

>
>- Image: https://pastebin.com/GRc1yErL
>- LVMVolumeGroup: https://pastebin.com/R1276gTu
>- SDM: https://pastebin.com/P3tfYEDD
>- StorageDomain: https://pastebin.com/Q0DxKgF5
>- StoragePool: https://pastebin.com/VXFWpfRC
>- VM: https://pastebin.com/tDC60c29
>- Volume: https://pastebin.com/TYkr9Zsd
>- |jobs|: https://pastebin.com/jeXpYyz9
>- |virt|: https://pastebin.com/nRREuEub
>
> Regards, Marcin
> ___
> 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/NW67DZSIMQTFB4HG6SDCACFFOY6CB2YN/
>
___
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/B27E7MY7QGK7GRZYI3X45VN6LTZLVJBC/

[ovirt-devel] Re: [VDSM] Started getting virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired

[Edward Haas]

> On 26 Sep 2018, at 19:42, Dan Kenigsberg  wrote:
> 
> 
> 
>> On Wed, Sep 26, 2018 at 6:35 PM Edward Haas  wrote:
>> I should have known better.
>> Deleting /etc/pki/vdsm and re-installing VDSM solved it.
>> 
>> There is probably a smarter/simpler way to do this (delete the folder and 
>> run 'vdsm-tool configure --force'?).
> 
> yes, more specifically: `vdsm-tool configure --module certificates`

I would expect running it or the other general version to replace the existing 
expired certificate.
At the minimum it should check and tell me what should I do.

> 
>> 
>> Thanks,
>> Edy.
>> 
>>> On Wed, Sep 26, 2018 at 6:16 PM Edward Haas  wrote:
>>> Hi,
>>> 
>>> I have a VM which acts as an oVirt host with VDSM installed. I use it for 
>>> testing without connecting it to Engine.
>>> 
>>> Recently VDSM fails to come up and I see this error:
>>> Sep 26 17:58:18 localhost libvirtd: 2018-09-26 14:58:18.978+: 12176: 
>>> error : virNetTLSContextCheckCertTimes:154 : The server certificate 
>>> /etc/pki/vdsm/certs/vdsmcert.pem has expired
> 
> Congratulations, you've been using the same deployment for a year!

I’m pretty sure I never had to delete that folder until now. Vdsm is built, 
installed and removed in an endless loop on a regular basis (including the 
configured part).

> 
>>> 
>>> Any hint on how to generate or fetch a new certificate without the help of 
>>> Engine?
>>> 
>>> Thanks,
>>> Edy.
>> ___
>> 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/MLAYDC74DYMHS7XML7IW2E7XVOUIB4TS/
___
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/P6C5OPGGWWGS3V7BJ6Q7G7JUVXQFOWEZ/

[ovirt-devel] Re: [VDSM] Started getting virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired

[Edward Haas]

I should have known better.
Deleting /etc/pki/vdsm and re-installing VDSM solved it.

There is probably a smarter/simpler way to do this (delete the folder and
run 'vdsm-tool configure --force'?).

Thanks,
Edy.

On Wed, Sep 26, 2018 at 6:16 PM Edward Haas  wrote:

> Hi,
>
> I have a VM which acts as an oVirt host with VDSM installed. I use it for
> testing without connecting it to Engine.
>
> Recently VDSM fails to come up and I see this error:
> Sep 26 17:58:18 localhost libvirtd: 2018-09-26 14:58:18.978+: 12176:
> error : virNetTLSContextCheckCertTimes:154 : The server certificate
> /etc/pki/vdsm/certs/vdsmcert.pem has expired
>
> Any hint on how to generate or fetch a new certificate without the help of
> Engine?
>
> Thanks,
> Edy.
>
___
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/MLAYDC74DYMHS7XML7IW2E7XVOUIB4TS/

[ovirt-devel] [VDSM] Started getting virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired

[Edward Haas]

Hi,

I have a VM which acts as an oVirt host with VDSM installed. I use it for
testing without connecting it to Engine.

Recently VDSM fails to come up and I see this error:
Sep 26 17:58:18 localhost libvirtd: 2018-09-26 14:58:18.978+: 12176:
error : virNetTLSContextCheckCertTimes:154 : The server certificate
/etc/pki/vdsm/certs/vdsmcert.pem has expired

Any hint on how to generate or fetch a new certificate without the help of
Engine?

Thanks,
Edy.
___
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/35B27JICDVDSABDGSEHTQDFXHP5IOAGI/

[ovirt-devel] Re: Failing Build On vdsm_master_check-patch

[Edward Haas]

I opened https://bugzilla.redhat.com/show_bug.cgi?id=1623488, and posted a
temporary workaround: https://gerrit.ovirt.org/#/c/94007
Unfortunately, the slaves are already contaminated and it will get cleaned
only if this workaround will run on it at least once (at that first time,
it will still fail but will cleanup after).

Thanks,
Edy.

On Wed, Aug 29, 2018 at 2:14 PM, Edward Haas  wrote:

> There is a problem with the fedora 28 "ip rule" output.
> I could not recreate it on an updated fc28 in the lab.
>
> Anton, I see on my setup this version: iproute-4.17.0-2.fc28.x86_64
> Could you please share what we have on the CI slaves?
>
> Thanks,
> Edy.
>
> On Wed, Aug 29, 2018 at 10:43 AM, Ales Musil  wrote:
>
>>
>>
>> On Wed, Aug 29, 2018 at 8:54 AM Shani Leviim  wrote:
>>
>>> Sorry, re-organizing:
>>>
>>> /vdsm_master_check-patch-fc28-x86_64/vdsm/vdsm was never imported.
>>> (module-not-imported)
>>> 14:33:56
>>> 14:33:56 
>>> ==
>>> 14:33:56 FAIL: test_sourceroute_add_remove_and_read
>>> (network.sourceroute_test.TestSourceRoute)
>>> 14:33:56 
>>> --
>>> 14:33:56 Traceback (most recent call last):
>>> 14:33:56   File "/home/jenkins/workspace/vdsm_
>>> master_check-patch-fc28-x86_64/vdsm/tests/testValidation.py", line 193,
>>> in wrapper
>>> 14:33:56 return f(*args, **kwargs)
>>> 14:33:56   File "/home/jenkins/workspace/vdsm_
>>> master_check-patch-fc28-x86_64/vdsm/tests/network/sourceroute_test.py",
>>> line 80, in test_sourceroute_add_remove_and_read
>>> 14:33:56 self.assertEqual(2, len(routes), routes)
>>> 14:33:56 AssertionError: 2 != 0
>>> 14:33:56  >> begin captured logging <<
>>> 
>>>
>>>
>>>
>>> *Regards,*
>>>
>>> *Shani Leviim*
>>>
>>> On Wed, Aug 29, 2018 at 9:48 AM, Shani Leviim 
>>> wrote:
>>>
>>>> Hello All,
>>>>
>>>> I got into the following failure during the CI build for a patch I did:
>>>>
>>>> 14:33:56 
>>>> ==
>>>> 14:33:56 FAIL: test_sourceroute_add_remove_and_read
>>>> (network.sourceroute_test.TestSourceRoute) 14:33:56
>>>> --
>>>> 14:33:56 Traceback (most recent call last): 14:33:56 File
>>>> "/home/jenkins/workspace/vdsm_master_check-patch-fc28-x86_64
>>>> /vdsm/tests/testValidation.py", line 193, in wrapper 14:33:56 return
>>>> f(*args, **kwargs) 14:33:56 File "/home/jenkins/workspace/vdsm_
>>>> master_check-patch-fc28-x86_64/vdsm/tests/network/sourceroute_test.py",
>>>> line 80, in test_sourceroute_add_remove_and_read 14:33:56
>>>> self.assertEqual(2, len(routes), routes) 14:33:56 AssertionError: 2 != 0
>>>>
>>>> My patch is [1] and its build is [2]
>>>>
>>>> [1] https://gerrit.ovirt.org/#/c/92416/
>>>> [2] http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc28-x8
>>>> 6_64/747/
>>>>
>>>> Can you please assist?
>>>> Thanks!
>>>>
>>>>
>>>> *Regards,*
>>>>
>>>> *Shani Leviim*
>>>>
>>>
>>> ___
>>> 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/communit
>>> y/about/community-guidelines/
>>> List Archives: https://lists.ovirt.org/archiv
>>> es/list/devel@ovirt.org/message/N4TIMBJYMM3ZXZZSN7M2QUS6VOQBA4YU/
>>>
>>
>> +Edy
>> --
>>
>> ALES MUSIL
>> Associate Software Engineer - rhv network
>>
>> Red Hat EMEA <https://www.redhat.com/>
>>
>>
>> amu...@redhat.com   IM: amusil
>> <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/D4JS7SMESRZFQLWYZQMNJNIIRSSWOKSO/

[ovirt-devel] Re: Failing Build On vdsm_master_check-patch

[Edward Haas]

There is a problem with the fedora 28 "ip rule" output.
I could not recreate it on an updated fc28 in the lab.

Anton, I see on my setup this version: iproute-4.17.0-2.fc28.x86_64
Could you please share what we have on the CI slaves?

Thanks,
Edy.

On Wed, Aug 29, 2018 at 10:43 AM, Ales Musil  wrote:

>
>
> On Wed, Aug 29, 2018 at 8:54 AM Shani Leviim  wrote:
>
>> Sorry, re-organizing:
>>
>> /vdsm_master_check-patch-fc28-x86_64/vdsm/vdsm was never imported.
>> (module-not-imported)
>> 14:33:56
>> 14:33:56 
>> ==
>> 14:33:56 FAIL: test_sourceroute_add_remove_and_read
>> (network.sourceroute_test.TestSourceRoute)
>> 14:33:56 
>> --
>> 14:33:56 Traceback (most recent call last):
>> 14:33:56   File "/home/jenkins/workspace/vdsm_
>> master_check-patch-fc28-x86_64/vdsm/tests/testValidation.py", line 193,
>> in wrapper
>> 14:33:56 return f(*args, **kwargs)
>> 14:33:56   File "/home/jenkins/workspace/vdsm_
>> master_check-patch-fc28-x86_64/vdsm/tests/network/sourceroute_test.py",
>> line 80, in test_sourceroute_add_remove_and_read
>> 14:33:56 self.assertEqual(2, len(routes), routes)
>> 14:33:56 AssertionError: 2 != 0
>> 14:33:56  >> begin captured logging <<
>> 
>>
>>
>>
>> *Regards,*
>>
>> *Shani Leviim*
>>
>> On Wed, Aug 29, 2018 at 9:48 AM, Shani Leviim  wrote:
>>
>>> Hello All,
>>>
>>> I got into the following failure during the CI build for a patch I did:
>>>
>>> 14:33:56 
>>> ==
>>> 14:33:56 FAIL: test_sourceroute_add_remove_and_read
>>> (network.sourceroute_test.TestSourceRoute) 14:33:56
>>> --
>>> 14:33:56 Traceback (most recent call last): 14:33:56 File
>>> "/home/jenkins/workspace/vdsm_master_check-patch-fc28-x86_
>>> 64/vdsm/tests/testValidation.py", line 193, in wrapper 14:33:56 return
>>> f(*args, **kwargs) 14:33:56 File "/home/jenkins/workspace/vdsm_
>>> master_check-patch-fc28-x86_64/vdsm/tests/network/sourceroute_test.py",
>>> line 80, in test_sourceroute_add_remove_and_read 14:33:56
>>> self.assertEqual(2, len(routes), routes) 14:33:56 AssertionError: 2 != 0
>>>
>>> My patch is [1] and its build is [2]
>>>
>>> [1] https://gerrit.ovirt.org/#/c/92416/
>>> [2] http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc28-
>>> x86_64/747/
>>>
>>> Can you please assist?
>>> Thanks!
>>>
>>>
>>> *Regards,*
>>>
>>> *Shani Leviim*
>>>
>>
>> ___
>> 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/N4TIMBJYMM3ZXZZSN7M2QUS6VOQBA4YU/
>>
>
> +Edy
> --
>
> ALES MUSIL
> Associate Software Engineer - rhv network
>
> Red Hat EMEA 
>
>
> amu...@redhat.com   IM: amusil
> 
>
___
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/DY66RSVV7L2Z6QH25ZOD7I4PZ4MPMR7J/

[ovirt-devel] Re: [VDSM] Travis builds still fail on .coverage rename

[Edward Haas]

On Sun, Jul 8, 2018 at 1:42 PM, Nir Soffer  wrote:

> On Sat, Jul 7, 2018 at 9:11 AM Edward Haas  wrote:
>
>> On Sat, Jul 7, 2018 at 9:02 AM, Edward Haas  wrote:
>>
>>>
>>>
>>> On Fri, Jul 6, 2018 at 9:16 PM, Nir Soffer  wrote:
>>>
>>>> On Fri, Jul 6, 2018 at 7:05 PM Edward Haas  wrote:
>>>>
>>>>>
>>>>>
>>>>> On 6 Jul 2018, at 18:41, Nir Soffer  wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Fri, 6 Jul 2018, 18:25 Edward Haas,  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 6 Jul 2018, at 14:35, Nir Soffer  wrote:
>>>>>>
>>>>>> On Fri, Jul 6, 2018 at 1:12 PM Edward Haas  wrote:
>>>>>>
>>>>>>> I do not know if it is relevant or not, but the tests that travis
>>>>>>> runs for master are taken from the 4.2 branch.
>>>>>>> OVS tests are now running using pytest.
>>>>>>>
>>>>>>
>>>>>> What do you mean by "taken from 4.2 branch"?
>>>>>>
>>>>>>
>>>>>> I mean that the branch checked out is 4.2 and not master. It even
>>>>>> says so on the console output.
>>>>>>
>>>>>
>>>>> Can you share the url of that build?
>>>>>
>>>>>
>>>>> I just clicked the icon on the vdsm repo: https://travis-ci.org/
>>>>> oVirt/vdsm
>>>>>
>>>>
>>>> This is indeed 4.2 build. Any commit in github is tested in travis.
>>>> We would like to fix also the 4.2 builds, but first we need to fix
>>>> master builds.
>>>>
>>>> You can see here that master build fail:
>>>> https://travis-ci.org/oVirt/vdsm/builds
>>>>
>>>> Since we added gbd and python-debuginfo:
>>>> https://travis-ci.org/oVirt/vdsm/builds/400644077
>>>>
>>>> - centos build fail (network-py27)
>>>>   https://travis-ci.org/oVirt/vdsm/jobs/400644079
>>>>
>>>> - fedora 28 build pass
>>>>   https://travis-ci.org/oVirt/vdsm/jobs/400644081
>>>>
>>>> - fedora rawhide fail because we cannot rebuild the image,
>>>>   python-libblokdev is missing in rawhide.
>>>>   https://travis-ci.org/oVirt/vdsm/jobs/400644083
>>>>   See https://lists.ovirt.org/archives/list/devel@ovirt.org/thread/
>>>> CDNETITY5RYOCQBIQQF2NUF6RAHGJRPW/
>>>>
>>>>
>>>>  I don't know anything about these tests, but this failure looks like:
>>>>
>>>> 1. first test has a timeout
>>>> 2. first test cleanup did not run because the cleanup code is not
>>>> correct
>>>> 3. second test fail because the first test did not clean up
>>>>
>>>> This looks like real issue in the code.
>>>>
>>>
>>> This is the same problem we had on oVirt CI, there are linux bridges on
>>> the node.
>>> I have posted a patch to fail earlier and how the real problem:
>>> https://gerrit.ovirt.org/#/c/92867/
>>> The travis-ci run for it is here: https://travis-ci.org/EdDev/
>>> vdsm/jobs/401143906
>>> This is the problem:
>>> cmdutils.py 151 DEBUG /usr/share/openvswitch/scripts/ovs-ctl
>>> --system-id=random start (cwd None)
>>> cmdutils.py 159 DEBUG FAILED:  = 'rmmod: ERROR: Module bridge is in
>>> use by: br_netfilter\n';  = 1
>>>
>>
> Who is using rmmod?
>

The ovs service is trying to load the ovs kmod, for doing so it needs to
take down the bridge one and reload it after the ovs one.


>
>> Any idea who is creating the "br_netfilter" bridge? I guess this is
>>> travis-ci related.
>>>
>>
> Why do we care about br_netfilter? do we require a system without any
> bridge?
>

Yes, in case ovs kmod has not been loaded in advance.


>
>
>> Actually, this may be Docker or some other package that is
>> installed/setup on it.
>> How can I run the docker with the tests locally to debug this?
>>
>
> Run this in vdsm root directory (copied from .travis.yml):
>
> export DOCKER_IMAGE=ovirtorg/vdsm-test-centos
>
> docker pull $DOCKER_IMAGE
>
> docker run \
> --env TRAVIS_CI=1 \
> --privileged \
> --rm \
> -it \
> -v `pwd`:/vdsm:Z \
> $DOCKER_IMAGE \

[ovirt-devel] Re: [VDSM] Travis builds still fail on .coverage rename

[Edward Haas]

> On 6 Jul 2018, at 18:41, Nir Soffer  wrote:
> 
> 
> 
>> On Fri, 6 Jul 2018, 18:25 Edward Haas,  wrote:
>> 
>> 
>>> On 6 Jul 2018, at 14:35, Nir Soffer  wrote:
>>> 
>>>> On Fri, Jul 6, 2018 at 1:12 PM Edward Haas  wrote:
>>>> I do not know if it is relevant or not, but the tests that travis runs for 
>>>> master are taken from the 4.2 branch.
>>>> OVS tests are now running using pytest.
>>> 
>>> What do you mean by "taken from 4.2 branch"?
>> 
>> I mean that the branch checked out is 4.2 and not master. It even says so on 
>> the console output.
> 
> 
> Can you share the url of that build?

I just clicked the icon on the vdsm repo: https://travis-ci.org/oVirt/vdsm

> 
>> 
>>> 
>>> We run "make check" both in travis (.travis.yml) and ovirt ci 
>>> (automation/check-patch.sh)
>>>  
>>>> 
>>>> 
>>>>> On Fri, Jul 6, 2018 at 12:51 AM, Nir Soffer  wrote:
>>>>> 
>>>>> 
>>>>>> On Thu, Jul 5, 2018 at 10:55 PM Nir Soffer  wrote:
>>>>>>> On Thu, Jul 5, 2018 at 5:53 PM Nir Soffer  wrote:
>>>>>>>> On Thu, Jul 5, 2018 at 5:43 PM Dan Kenigsberg  
>>>>>>>> wrote:
>>>>>>>> On Thu, Jul 5, 2018 at 2:52 AM, Nir Soffer  wrote:
>>>>>>>> > On Wed, Jul 4, 2018 at 1:00 PM Dan Kenigsberg  
>>>>>>>> > wrote:
>>>>>>>> >>
>>>>>>>> >> On Wed, Jul 4, 2018 at 12:48 PM, Nir Soffer  
>>>>>>>> >> wrote:
>>>>>>>> >> > Dan, travis build still fail when renaming coverage file even 
>>>>>>>> >> > after
>>>>>>>> >> > your last patch.
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> >> > ...SS.SS.SS..S.SSSS.SSS...SSS...S.S.SSSS..S.SS..
>>>>>>>> >> > --
>>>>>>>> >> > Ran 1267 tests in 99.239s
>>>>>>>> >> > OK (SKIP=63)
>>>>>>>> >> > [ -n "$NOSE_WITH_COVERAGE" ] && mv .coverage .coverage-nose-py2
>>>>>>>> >> > make[1]: *** [check] Error 1
>>>>>>>> >> > make[1]: Leaving directory `/vdsm/tests'
>>>>>>>> >> > ERROR: InvocationError: '/usr/bin/make -C tests check'
>>>>>>>> >> >
>>>>>>>> >> > https://travis-ci.org/oVirt/vdsm/jobs/399932012
>>>>>>>> >> >
>>>>>>>> >> > Do you have any idea what is wrong there?
>>>>>>>> >> >
>>>>>>>> >> > Why we don't have any error message from the failed command?
>>>>>>>> >>
>>>>>>>> >> No idea, nothing pops to mind.
>>>>>>>> >> We can revert to the sillier [ -f .coverage ] condition instead of
>>>>>>>> >> understanding (yeah, this feels dirty)
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > Thanks, your patch (https://gerrit.ovirt.org/#/c/92813/) fixed this
>>>>>>>> > failure.
>>>>>>>> >
>>>>>>>> > Now we have failures for the pywatch_test, and some network
>>>>>>>> > tests. Can someone from network look at this?
>>>>>>>> > https://travis-ci.org/nirs/vdsm/builds/400204807
>>>>>>>> 
>>>>>>>> https://travis-ci.org/nirs/vdsm/jobs/400204808 shows

[ovirt-devel] Re: [VDSM] Travis builds still fail on .coverage rename

[Edward Haas]

> On 6 Jul 2018, at 14:35, Nir Soffer  wrote:
> 
>> On Fri, Jul 6, 2018 at 1:12 PM Edward Haas  wrote:
>> I do not know if it is relevant or not, but the tests that travis runs for 
>> master are taken from the 4.2 branch.
>> OVS tests are now running using pytest.
> 
> What do you mean by "taken from 4.2 branch"?

I mean that the branch checked out is 4.2 and not master. It even says so on 
the console output.

> 
> We run "make check" both in travis (.travis.yml) and ovirt ci 
> (automation/check-patch.sh)
>  
>> 
>> 
>>> On Fri, Jul 6, 2018 at 12:51 AM, Nir Soffer  wrote:
>>> 
>>> 
>>>> On Thu, Jul 5, 2018 at 10:55 PM Nir Soffer  wrote:
>>>>> On Thu, Jul 5, 2018 at 5:53 PM Nir Soffer  wrote:
>>>>>> On Thu, Jul 5, 2018 at 5:43 PM Dan Kenigsberg  wrote:
>>>>>> On Thu, Jul 5, 2018 at 2:52 AM, Nir Soffer  wrote:
>>>>>> > On Wed, Jul 4, 2018 at 1:00 PM Dan Kenigsberg  
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> On Wed, Jul 4, 2018 at 12:48 PM, Nir Soffer  
>>>>>> >> wrote:
>>>>>> >> > Dan, travis build still fail when renaming coverage file even after
>>>>>> >> > your last patch.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > ...SS.SS.SS..S.SSSS.SSS...SSS...S.S.SSSS..S.SS..
>>>>>> >> > --
>>>>>> >> > Ran 1267 tests in 99.239s
>>>>>> >> > OK (SKIP=63)
>>>>>> >> > [ -n "$NOSE_WITH_COVERAGE" ] && mv .coverage .coverage-nose-py2
>>>>>> >> > make[1]: *** [check] Error 1
>>>>>> >> > make[1]: Leaving directory `/vdsm/tests'
>>>>>> >> > ERROR: InvocationError: '/usr/bin/make -C tests check'
>>>>>> >> >
>>>>>> >> > https://travis-ci.org/oVirt/vdsm/jobs/399932012
>>>>>> >> >
>>>>>> >> > Do you have any idea what is wrong there?
>>>>>> >> >
>>>>>> >> > Why we don't have any error message from the failed command?
>>>>>> >>
>>>>>> >> No idea, nothing pops to mind.
>>>>>> >> We can revert to the sillier [ -f .coverage ] condition instead of
>>>>>> >> understanding (yeah, this feels dirty)
>>>>>> >
>>>>>> >
>>>>>> > Thanks, your patch (https://gerrit.ovirt.org/#/c/92813/) fixed this
>>>>>> > failure.
>>>>>> >
>>>>>> > Now we have failures for the pywatch_test, and some network
>>>>>> > tests. Can someone from network look at this?
>>>>>> > https://travis-ci.org/nirs/vdsm/builds/400204807
>>>>>> 
>>>>>> https://travis-ci.org/nirs/vdsm/jobs/400204808 shows
>>>>>> 
>>>>>>   ConfigNetworkError: (21, 'Executing commands failed:
>>>>>> ovs-vsctl: cannot create a bridge named vdsmbr_test because a bridge
>>>>>> named vdsmbr_test already exists')
>>>>>> 
>>>>>> which I thought was limited to dirty ovirt-ci jenkins slaves. Any idea
>>>>>> why it shows here?
>>>>> 
>>>>> Maybe one failed test leave dirty host to the next test?
>>> 
>>> network tests fail now only on CentOS now.
>>>  
>>>>>  
>>>>>> py-watch seems to be failing due to missing gdb on the travis image
>>>>>> 
>>>>>> cmdutils.py151 DEBUG./py-watch 0.1 sleep 10 (cw

[ovirt-devel] Re: [VDSM] Travis builds still fail on .coverage rename

[Edward Haas]

On Sat, Jul 7, 2018 at 9:02 AM, Edward Haas  wrote:

>
>
> On Fri, Jul 6, 2018 at 9:16 PM, Nir Soffer  wrote:
>
>> On Fri, Jul 6, 2018 at 7:05 PM Edward Haas  wrote:
>>
>>>
>>>
>>> On 6 Jul 2018, at 18:41, Nir Soffer  wrote:
>>>
>>>
>>>
>>> On Fri, 6 Jul 2018, 18:25 Edward Haas,  wrote:
>>>
>>>>
>>>>
>>>> On 6 Jul 2018, at 14:35, Nir Soffer  wrote:
>>>>
>>>> On Fri, Jul 6, 2018 at 1:12 PM Edward Haas  wrote:
>>>>
>>>>> I do not know if it is relevant or not, but the tests that travis runs
>>>>> for master are taken from the 4.2 branch.
>>>>> OVS tests are now running using pytest.
>>>>>
>>>>
>>>> What do you mean by "taken from 4.2 branch"?
>>>>
>>>>
>>>> I mean that the branch checked out is 4.2 and not master. It even says
>>>> so on the console output.
>>>>
>>>
>>> Can you share the url of that build?
>>>
>>>
>>> I just clicked the icon on the vdsm repo: https://travis-ci.org/oV
>>> irt/vdsm
>>>
>>
>> This is indeed 4.2 build. Any commit in github is tested in travis.
>> We would like to fix also the 4.2 builds, but first we need to fix master
>> builds.
>>
>> You can see here that master build fail:
>> https://travis-ci.org/oVirt/vdsm/builds
>>
>> Since we added gbd and python-debuginfo:
>> https://travis-ci.org/oVirt/vdsm/builds/400644077
>>
>> - centos build fail (network-py27)
>>   https://travis-ci.org/oVirt/vdsm/jobs/400644079
>>
>> - fedora 28 build pass
>>   https://travis-ci.org/oVirt/vdsm/jobs/400644081
>>
>> - fedora rawhide fail because we cannot rebuild the image,
>>   python-libblokdev is missing in rawhide.
>>   https://travis-ci.org/oVirt/vdsm/jobs/400644083
>>   See https://lists.ovirt.org/archives/list/devel@ovirt.org/th
>> read/CDNETITY5RYOCQBIQQF2NUF6RAHGJRPW/
>>
>>
>>  I don't know anything about these tests, but this failure looks like:
>>
>> 1. first test has a timeout
>> 2. first test cleanup did not run because the cleanup code is not correct
>> 3. second test fail because the first test did not clean up
>>
>> This looks like real issue in the code.
>>
>
> This is the same problem we had on oVirt CI, there are linux bridges on
> the node.
> I have posted a patch to fail earlier and how the real problem:
> https://gerrit.ovirt.org/#/c/92867/
> The travis-ci run for it is here: https://travis-ci.org/EdDev/
> vdsm/jobs/401143906
> This is the problem:
> cmdutils.py 151 DEBUG /usr/share/openvswitch/scripts/ovs-ctl
> --system-id=random start (cwd None)
> cmdutils.py 159 DEBUG FAILED:  = 'rmmod: ERROR: Module bridge is in
> use by: br_netfilter\n';  = 1
>
> Any idea who is creating the "br_netfilter" bridge? I guess this is
> travis-ci related.
>

Actually, this may be Docker or some other package that is installed/setup
on it.
How can I run the docker with the tests locally to debug this?


>
>
Thanks,
> Edy.
>
>
>>
>>>
>>>>
>>>> We run "make check" both in travis (.travis.yml) and ovirt ci
>>>> (automation/check-patch.sh)
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 6, 2018 at 12:51 AM, Nir Soffer 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 5, 2018 at 10:55 PM Nir Soffer 
>>>>>> wrote:
>>>>>>
>>>>>>> On Thu, Jul 5, 2018 at 5:53 PM Nir Soffer 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Thu, Jul 5, 2018 at 5:43 PM Dan Kenigsberg 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Thu, Jul 5, 2018 at 2:52 AM, Nir Soffer 
>>>>>>>>> wrote:
>>>>>>>>> > On Wed, Jul 4, 2018 at 1:00 PM Dan Kenigsberg 
>>>>>>>>> wrote:
>>>>>>>>> >>
>>>>>>>>> >> On Wed, Jul 4, 2018 at 12:48 PM, Nir Soffer 
>>>>>>>>> wrote:
>>>>>>>>> >> > Dan, travis build still fail when renaming coverage file even
>>>>>>>>> after
>>>>>>>>> >> > your last patch.
>>>>>>>>

[ovirt-devel] Re: [VDSM] Travis builds still fail on .coverage rename

[Edward Haas]

On Fri, Jul 6, 2018 at 9:16 PM, Nir Soffer  wrote:

> On Fri, Jul 6, 2018 at 7:05 PM Edward Haas  wrote:
>
>>
>>
>> On 6 Jul 2018, at 18:41, Nir Soffer  wrote:
>>
>>
>>
>> On Fri, 6 Jul 2018, 18:25 Edward Haas,  wrote:
>>
>>>
>>>
>>> On 6 Jul 2018, at 14:35, Nir Soffer  wrote:
>>>
>>> On Fri, Jul 6, 2018 at 1:12 PM Edward Haas  wrote:
>>>
>>>> I do not know if it is relevant or not, but the tests that travis runs
>>>> for master are taken from the 4.2 branch.
>>>> OVS tests are now running using pytest.
>>>>
>>>
>>> What do you mean by "taken from 4.2 branch"?
>>>
>>>
>>> I mean that the branch checked out is 4.2 and not master. It even says
>>> so on the console output.
>>>
>>
>> Can you share the url of that build?
>>
>>
>> I just clicked the icon on the vdsm repo: https://travis-ci.org/
>> oVirt/vdsm
>>
>
> This is indeed 4.2 build. Any commit in github is tested in travis.
> We would like to fix also the 4.2 builds, but first we need to fix master
> builds.
>
> You can see here that master build fail:
> https://travis-ci.org/oVirt/vdsm/builds
>
> Since we added gbd and python-debuginfo:
> https://travis-ci.org/oVirt/vdsm/builds/400644077
>
> - centos build fail (network-py27)
>   https://travis-ci.org/oVirt/vdsm/jobs/400644079
>
> - fedora 28 build pass
>   https://travis-ci.org/oVirt/vdsm/jobs/400644081
>
> - fedora rawhide fail because we cannot rebuild the image,
>   python-libblokdev is missing in rawhide.
>   https://travis-ci.org/oVirt/vdsm/jobs/400644083
>   See https://lists.ovirt.org/archives/list/devel@ovirt.org/thread/
> CDNETITY5RYOCQBIQQF2NUF6RAHGJRPW/
>
>
>  I don't know anything about these tests, but this failure looks like:
>
> 1. first test has a timeout
> 2. first test cleanup did not run because the cleanup code is not correct
> 3. second test fail because the first test did not clean up
>
> This looks like real issue in the code.
>

This is the same problem we had on oVirt CI, there are linux bridges on the
node.
I have posted a patch to fail earlier and how the real problem:
https://gerrit.ovirt.org/#/c/92867/
The travis-ci run for it is here:
https://travis-ci.org/EdDev/vdsm/jobs/401143906
This is the problem:
cmdutils.py 151 DEBUG /usr/share/openvswitch/scripts/ovs-ctl
--system-id=random start (cwd None)
cmdutils.py 159 DEBUG FAILED:  = 'rmmod: ERROR: Module bridge is in
use by: br_netfilter\n';  = 1

Any idea who is creating the "br_netfilter" bridge? I guess this is
travis-ci related.

Thanks,
Edy.


>
>>
>>>
>>> We run "make check" both in travis (.travis.yml) and ovirt ci
>>> (automation/check-patch.sh)
>>>
>>>
>>>>
>>>>
>>>> On Fri, Jul 6, 2018 at 12:51 AM, Nir Soffer  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 5, 2018 at 10:55 PM Nir Soffer  wrote:
>>>>>
>>>>>> On Thu, Jul 5, 2018 at 5:53 PM Nir Soffer  wrote:
>>>>>>
>>>>>>> On Thu, Jul 5, 2018 at 5:43 PM Dan Kenigsberg 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Thu, Jul 5, 2018 at 2:52 AM, Nir Soffer 
>>>>>>>> wrote:
>>>>>>>> > On Wed, Jul 4, 2018 at 1:00 PM Dan Kenigsberg 
>>>>>>>> wrote:
>>>>>>>> >>
>>>>>>>> >> On Wed, Jul 4, 2018 at 12:48 PM, Nir Soffer 
>>>>>>>> wrote:
>>>>>>>> >> > Dan, travis build still fail when renaming coverage file even
>>>>>>>> after
>>>>>>>> >> > your last patch.
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> >> >
>>>>>>>> >> > ...SS.SS
>>>>>>>> 
>>>>>>>> 
>>>>>>>> .SS.
>>>>>>>> .S.SS...
>>>>>>>> .SS.SS..
>>>>>>>> ..S...SSS...S.S.
>>>

[ovirt-devel] Re: [VDSM] Travis builds still fail on .coverage rename

[Edward Haas]

I do not know if it is relevant or not, but the tests that travis runs for
master are taken from the 4.2 branch.
OVS tests are now running using pytest.


On Fri, Jul 6, 2018 at 12:51 AM, Nir Soffer  wrote:

>
>
> On Thu, Jul 5, 2018 at 10:55 PM Nir Soffer  wrote:
>
>> On Thu, Jul 5, 2018 at 5:53 PM Nir Soffer  wrote:
>>
>>> On Thu, Jul 5, 2018 at 5:43 PM Dan Kenigsberg  wrote:
>>>
 On Thu, Jul 5, 2018 at 2:52 AM, Nir Soffer  wrote:
 > On Wed, Jul 4, 2018 at 1:00 PM Dan Kenigsberg 
 wrote:
 >>
 >> On Wed, Jul 4, 2018 at 12:48 PM, Nir Soffer 
 wrote:
 >> > Dan, travis build still fail when renaming coverage file even after
 >> > your last patch.
 >> >
 >> >
 >> >
 >> > ...SS.SS
 
 
 .SS.
 .S.SS...
 .SS.SS..
 ..S...SSS...S.S.
 S...
 .SSS..S.SS..
 
 
 
 >> > 
 --
 >> > Ran 1267 tests in 99.239s
 >> > OK (SKIP=63)
 >> > [ -n "$NOSE_WITH_COVERAGE" ] && mv .coverage .coverage-nose-py2
 >> > make[1]: *** [check] Error 1
 >> > make[1]: Leaving directory `/vdsm/tests'
 >> > ERROR: InvocationError: '/usr/bin/make -C tests check'
 >> >
 >> > https://travis-ci.org/oVirt/vdsm/jobs/399932012
 >> >
 >> > Do you have any idea what is wrong there?
 >> >
 >> > Why we don't have any error message from the failed command?
 >>
 >> No idea, nothing pops to mind.
 >> We can revert to the sillier [ -f .coverage ] condition instead of
 >> understanding (yeah, this feels dirty)
 >
 >
 > Thanks, your patch (https://gerrit.ovirt.org/#/c/92813/) fixed this
 > failure.
 >
 > Now we have failures for the pywatch_test, and some network
 > tests. Can someone from network look at this?
 > https://travis-ci.org/nirs/vdsm/builds/400204807

 https://travis-ci.org/nirs/vdsm/jobs/400204808 shows

   ConfigNetworkError: (21, 'Executing commands failed:
 ovs-vsctl: cannot create a bridge named vdsmbr_test because a bridge
 named vdsmbr_test already exists')

 which I thought was limited to dirty ovirt-ci jenkins slaves. Any idea
 why it shows here?

>>>
>>> Maybe one failed test leave dirty host to the next test?
>>>
>>
> network tests fail now only on CentOS now.
>
>
>>
>>>
 py-watch seems to be failing due to missing gdb on the travis image
>>>
>>>
 cmdutils.py151 DEBUG./py-watch 0.1 sleep 10 (cwd
 None)
 cmdutils.py159 DEBUGFAILED:  = 'Traceback
 (most recent call last):\n  File "./py-watch", line 60, in \n
   dump_trace(watched_proc)\n  File "./py-watch", line 32, in
 dump_trace\n\'thread apply all py-bt\'])\n  File
 "/usr/lib64/python2.7/site-packages/subprocess32.py", line 575, in
 call\np = Popen(*popenargs, **kwargs)\n  File
 "/usr/lib64/python2.7/site-packages/subprocess32.py", line 822, in
 __init__\nrestore_signals, start_new_session)\n  File
 "/usr/lib64/python2.7/site-packages/subprocess32.py", line 1567, in
 _execute_child\nraise child_exception_type(errno_num,
 err_msg)\nOSError: [Errno 2] No such file or directory: \'gdb\'\n';
  = 1

>>>
>>> Cool, easy fix.
>>>
>>
>> Fixed by https://gerrit.ovirt.org/#/c/92846/
>>
>
> Fedora 28 build is green with this change:
> https://travis-ci.org/nirs/vdsm/jobs/400549561
>
>
>
> ___ summary 
> 
>   tests: commands succeeded
>   storage-py27: commands succeeded
>   storage-py36: commands succeeded
>   lib-py27: commands succeeded
>   lib-py36: commands succeeded
>   network-py27: commands succeeded
>   network-py36: commands succeeded
>   virt-py27: commands succeeded
>   virt-py36: commands succeeded
>   congratulations :)
>
>
>
>>
>>>
>>>
 Nir, could you remind me what is "ERROR: InterpreterNotFound:
 python3.6" and how can we avoid it? it keeps distracting during
 debugging test failures.

>>>
>>> We can avoid it in travis using env matrix.
>>>
>>> Currently we run "make check" which run all the the tox envs
>>> (e.g. storage-py27,storage-py36) regardless of the build type. This is
>>> good
>>> for manual usage when you don't know which python version is

[ovirt-devel] Re: Propose Milan Zamazal as virt maintainer

[Edward Haas]

+1

Thanks,
Edy.

> On 4 Jun 2018, at 13:47, Dan Kenigsberg  wrote:
> 
> Approved.
> 
> On Mon, Jun 4, 2018 at 12:02 PM, Piotr Kliczewski
>  wrote:
>> +1
>> 
>>> On Thu, May 31, 2018 at 8:39 AM, Arik Hadas  wrote:
>>> 
>>> 
 On Thu, May 31, 2018 at 1:46 AM, Nir Soffer  wrote:
 
 On Wed, May 30, 2018 at 11:23 AM Francesco Romani 
 wrote:
> 
> Hi all,
> 
> Milan Zamazal has been working on the oVirt project for more than 2.5
> years.
> Let me highlight some of his many contributions to the project:
> 
> - Since January this year - 2018, he's been a maintainer for the stable
> branches.
> - He developed important features like memory hotunplug, which required
> tight cooperation
>  and communication with the other layers of the stack (libvirt, qemu).
> - He is a mentor in the Outreachy program, which lead to creation of the
> oVirt Log Analyzer: https://github.com/mz-pdm/ovirt-log-analyzer
> - He contributed more than 290 patches to the Vdsm project in master
> branch alone, excluding backports and contributions to Engine
> - He contributed and is contributing testcases and fixes to the oVirt
> System Test suite, a tool which was already pivotal in ensuring the
> quality of the oVirt project.
> 
> As reviewer, Milan is responsive and his comments are always
> comprehensive and  well focused,
> with strong attitude towards getting things done and done right.
> 
> Milan also demonstrated his ability to adapt to the needs of the project:
> - he demonstrated careful and thoughtful patch management while
> maintaining the stable branches
> - he also demonstrated he's not shy to tackle large and needed changes
> during the 4.1 and 4.2 cycles,
>  when we deeply reorganized the XML processing in the virt code.
> 
> For those reasons, and many more, I think he will be a good addition to
> the maintainers team, and I propose him as virt co-maintainer.
> 
> Please share your thoughts
 
 
 +1
>>> 
>>> 
>>> FWIW, +1
>>> 
 
 
 Nir
 
 
 ___
 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/QELJ7YNZVW65HXN5KGRKYUR5F334BA2X/
 
>>> 
>>> 
>>> ___
>>> 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/YIMB6QHQ37DVL46Z6OEULJEMSYGDTM2R/
>>> 
>> ___
>> 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/YBK7IHQELSEFN56WZHK6F7UCSPVT2H73/
___
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/JXGEOUNDA6RMB7XBAUXI66KPTGKNAVMX/

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

[Edward Haas]

On Sun, Apr 8, 2018 at 9:15 AM, Eyal Edri  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  wrote:
>
>> On 7 April 2018 at 00:30, Dan Kenigsberg  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?


>
>> at this point I think we should seriously consider disabling the
>> relevant test, as its impacting a large number of changes.
>>
>> > On Fri, Apr 6, 2018 at 2:20 PM, Dafna Ron  wrote:
>> >> Dan, was there a fix for the issues?
>> >> can I have a link to the fix if there was?
>> >>
>> >> Thanks,
>> >> Dafna
>> >>
>> >>
>> >> On Wed, Apr 4, 2018 at 5:01 PM, Gal Ben Haim 
>> wrote:
>> >>>
>> >>> 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 
>> wrote:
>> 
>>  On Wed, Apr 4, 2018 at 4:59 PM, Barak Korren 
>> 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/1
>> 537/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/1
>> 537/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/1
>> 537/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.

Re: [ovirt-devel] [vdsm] network test failure

[Edward Haas]

On Wed, Mar 21, 2018 at 12:15 PM, Petr Horacek  wrote:

> I tried to retrigger the build several times, it was always executed on
> el7 machine, maybe it picks fc26 only when all other machines are taken?
>
> Shouldn't be "Permission denied" problem detected in
> link_bond_test.py:setup_module()? It runs "check_sysfs_bond_permission".
>

I think that the error is from attempting to set a values that is not
acceptable by the attribute, not because there is no permission to access
sysfs.


> 2018-03-20 18:12 GMT+01:00 Edward Haas :
>
>> The tests ran on a fc26 slave and our bond option default map is in sync
>> with the el7 kernel.
>> It looks like we MUST generate a bond default map on every run.
>>
>> I'm a bit surprised it never happened until now, perhaps I'm not
>> interpreting correctly the tests helper  code? Petr?
>> Assuming I'm correct here, I'll try to post a fix.
>>
>> Thanks,
>> Edy.
>>
>> On Tue, Mar 20, 2018 at 12:14 PM, Dan Kenigsberg 
>> wrote:
>>
>>> +Petr
>>>
>>> On Tue, Mar 20, 2018 at 11:07 AM, Francesco Romani 
>>> wrote:
>>> > Hi all,
>>> >
>>> >
>>> > we had a bogus failure on CI again, some network test failed and it
>>> > seems totally unrelated to the patch being tested:
>>> >
>>> >
>>> > http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86
>>> _64/22410/consoleFull
>>> >
>>> >
>>> > could someone please have a look?
>>> >
>>> >
>>> > Bests,
>>> >
>>> > --
>>> > Francesco Romani
>>> > Senior SW Eng., Virtualization R&D
>>> > Red Hat
>>> > IRC: fromani github: @fromanirh
>>> >
>>>
>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [vdsm] network test failure

[Edward Haas]

The tests ran on a fc26 slave and our bond option default map is in sync
with the el7 kernel.
It looks like we MUST generate a bond default map on every run.

I'm a bit surprised it never happened until now, perhaps I'm not
interpreting correctly the tests helper  code? Petr?
Assuming I'm correct here, I'll try to post a fix.

Thanks,
Edy.

On Tue, Mar 20, 2018 at 12:14 PM, Dan Kenigsberg  wrote:

> +Petr
>
> On Tue, Mar 20, 2018 at 11:07 AM, Francesco Romani 
> wrote:
> > Hi all,
> >
> >
> > we had a bogus failure on CI again, some network test failed and it
> > seems totally unrelated to the patch being tested:
> >
> >
> > http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-
> x86_64/22410/consoleFull
> >
> >
> > could someone please have a look?
> >
> >
> > Bests,
> >
> > --
> > Francesco Romani
> > Senior SW Eng., Virtualization R&D
> > Red Hat
> > IRC: fromani github: @fromanirh
> >
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [VDSM] Remove fcraw build as gating

[Edward Haas]

Hi All,

Fcraw build on VDSM check-patch has been failing recently (again).

fcraw cannot act as gating to the VDSM CI, as it is unstable (by
definition).
If there is a strong interest for some to track VDSM against this unstable
distribution, it better be performed in parallel to the VDSM developing
flow.

With the current state, we are unable to trust the CI and it causes us to
either overwrite its output (which I consider very bad) or just get stuck
frequently.

Could we please move this job to be triggered once a day as a nightly job
and whoever is interested in its output to get notifications for it?
Please. lets not make it a gating to VDSM development.

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

[ovirt-devel] [VDSM] Failing CI check-patch on master, el7: Missing ppc64 repos

[Edward Haas]

Hello,

VDSM check-patch on master started to fail, looks like some repos vanished.

http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/21853/console

Can someone have a look? (Do we need ppc64? Why it was removed?)

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

Re: [ovirt-devel] [vdsm][network] false test failiures in CI

[Edward Haas]

Looks like IPv6 is disabled on that slave, therefore all IPv6 related tests
failed.
We will add a test to check IPv6 availability so we can easily detect this
in advance, but we do require IPv6 to be available.

Opening a ticker with infra-support.

On Tue, Feb 20, 2018 at 1:20 PM, Francesco Romani 
wrote:

> Hi there,
>
>
> recently some patches of mine failed on CI with this error which is
> totally unrelated and which seems bogus.
>
> Could some network developer please have a look and improve the current
> state? :)
>
>
> https://gerrit.ovirt.org/#/c/87881/
>
> 19:43:33
> ==
> 19:43:33 ERROR: test_list_ipv4_ipv6
> (network.ip_address_test.IPAddressTest) 19:43:33
> --
> 19:43:33 Traceback (most recent call last): 19:43:33 File
> "/home/jenkins/workspace/vdsm_4.2_check-patch-fc27-x86_64/
> vdsm/tests/testValidation.py",
> line 330, in wrapper 19:43:33 return f(*args, **kwargs) 19:43:33 File
> "/home/jenkins/workspace/vdsm_4.2_check-patch-fc27-x86_64/
> vdsm/tests/network/ip_address_test.py",
> line 289, in test_list_ipv4_ipv6 19:43:33
> ipv6_addresses=[IPV6_B_WITH_PREFIXLEN] 19:43:33 File
> "/home/jenkins/workspace/vdsm_4.2_check-patch-fc27-x86_64/
> vdsm/tests/network/ip_address_test.py",
> line 297, in _test_list 19:43:33 address.IPAddressData(addr,
> device=nic)) 19:43:33 File
> "/home/jenkins/workspace/vdsm_4.2_check-patch-fc27-x86_64/
> vdsm/lib/vdsm/network/ip/address/iproute2.py",
> line 40, in add 19:43:33 addr_data.address, addr_data.prefixlen,
> addr_data.family 19:43:33 File "/usr/lib64/python2.7/contextlib.py",
> line 35, in __exit__ 19:43:33 self.gen.throw(type, value, traceback)
> 19:43:33 File
> "/home/jenkins/workspace/vdsm_4.2_check-patch-fc27-x86_64/
> vdsm/lib/vdsm/network/ip/address/iproute2.py",
> line 91, in _translate_iproute2_exception 19:43:33 new_exception,
> new_exception(str(address_data), error_message), tb) 19:43:33 File
> "/home/jenkins/workspace/vdsm_4.2_check-patch-fc27-x86_64/
> vdsm/lib/vdsm/network/ip/address/iproute2.py",
> line 86, in _translate_iproute2_exception 19:43:33 yield 19:43:33 File
> "/home/jenkins/workspace/vdsm_4.2_check-patch-fc27-x86_64/
> vdsm/lib/vdsm/network/ip/address/iproute2.py",
> line 40, in add 19:43:33 addr_data.address, addr_data.prefixlen,
> addr_data.family 19:43:33 File
> "/home/jenkins/workspace/vdsm_4.2_check-patch-fc27-x86_64/
> vdsm/lib/vdsm/network/ipwrapper.py",
> line 561, in addrAdd 19:43:33 _exec_cmd(command) 19:43:33 File
> "/home/jenkins/workspace/vdsm_4.2_check-patch-fc27-x86_64/
> vdsm/lib/vdsm/network/ipwrapper.py",
> line 482, in _exec_cmd 19:43:33 raise exc(returnCode,
> error.splitlines()) 19:43:33 IPAddressAddError:
> ("IPAddressData(device='dummy_ZVN3L'
> address=IPv6Interface(u'2002:99::1/64') scope=None flags=None)",
> 'RTNETLINK answers: Permission denied')
>
>
> I had other failures, but they look like known issues (mkimage, no port
> on protocol detector)
>
>
> --
> Francesco Romani
> Senior SW Eng., Virtualization R&D
> Red Hat
> IRC: fromani github: @fromanirh
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] network tests failing the build again

[Edward Haas]

On Thu, Feb 8, 2018 at 3:07 PM, Nir Soffer  wrote:

> On Thu, Feb 8, 2018 at 2:52 PM Dan Kenigsberg  wrote:
>
>> On Thu, Feb 8, 2018 at 2:33 PM, Nir Soffer  wrote:
>> > Did we changes something in the CI or the network code? We see the
>> following
>> > failures since yesterday.
>> >
>> > I'm ignoring the failures since they are not related to the patch, but
>> > checking these
>> > failures waste lot time.
>> >
>> > Can someone from network look at this?
>>
>> We are. Fedora broke us
>> Bug 1543320 - Regression in lshw json output format.
>>
>
> Great. So mark the tests as xfail on fedora 27?
>

Negative, VDSM is broken on fc27.


>
>>
>> >
>> > http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-
>> x86_64/1283/consoleFull
>> >
>> > 00:04:37.280
>> > ==
>> > 00:04:37.280 ERROR: test_identify_non_vlan_base_device
>> > (network.link_vlan_test.LinkIfaceTests)
>> > 00:04:37.281
>> > --
>> > 00:04:37.281 Traceback (most recent call last):
>> > 00:04:37.281   File
>> > "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_
>> 64/vdsm/tests/network/link_vlan_test.py",
>> > line 46, in test_identify_non_vlan_base_device
>> > 00:04:37.282 self.assertFalse(vlan.is_base_device(nic))
>> > 00:04:37.283   File
>> > "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_
>> 64/vdsm/lib/vdsm/network/link/vlan.py",
>> > line 47, in is_base_device
>> > 00:04:37.283 return any(get_vlans_on_base_device(dev_name))
>> > 00:04:37.284   File
>> > "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_
>> 64/vdsm/lib/vdsm/network/link/vlan.py",
>> > line 41, in 
>> > 00:04:37.284 return (iface_properties['name'] for iface_properties
>> in
>> > iface.list()
>> > 00:04:37.285   File
>> > "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_
>> 64/vdsm/lib/vdsm/network/link/iface.py",
>> > line 227, in list
>> > 00:04:37.285 in six.viewitems(dpdk.get_dpdk_devices()))
>> > 00:04:37.286   File
>> > "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_
>> 64/vdsm/lib/vdsm/network/link/dpdk.py",
>> > line 47, in get_dpdk_devices
>> > 00:04:37.287 dpdk_devices = _get_dpdk_devices()
>> > 00:04:37.287   File
>> > "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_
>> 64/vdsm/lib/vdsm/common/cache.py",
>> > line 41, in __call__
>> > 00:04:37.287 value = self.func(*args)
>> > 00:04:37.288   File
>> > "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_
>> 64/vdsm/lib/vdsm/network/link/dpdk.py",
>> > line 111, in _get_dpdk_devices
>> > 00:04:37.288 devices = _lshw_command()
>> > 00:04:37.289   File
>> > "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_
>> 64/vdsm/lib/vdsm/network/link/dpdk.py",
>> > line 127, in _lshw_command
>> > 00:04:37.289 return _normalize_lshw_result(out)
>> > 00:04:37.290   File
>> > "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_
>> 64/vdsm/lib/vdsm/network/link/dpdk.py",
>> > line 182, in _normalize_lshw_result
>> > 00:04:37.290 return json.loads('[' + result + ']')
>> > 00:04:37.291   File "/usr/lib64/python2.7/json/__init__.py", line 339,
>> in
>> > loads
>> > 00:04:37.291 return _default_decoder.decode(s)
>> > 00:04:37.291   File "/usr/lib64/python2.7/json/decoder.py", line 364,
>> in
>> > decode
>> > 00:04:37.292 obj, end = self.raw_decode(s, idx=_w(s, 0).end())
>> > 00:04:37.292   File "/usr/lib64/python2.7/json/decoder.py", line 380,
>> in
>> > raw_decode
>> > 00:04:37.292 obj, end = self.scan_once(s, idx)
>> > 00:04:37.293 ValueError: Expecting , delimiter: line 11 column 8 (char
>> 242)
>> > 00:04:37.293  >> begin captured logging <<
>> > 
>> > 00:04:37.294 2018-02-08 11:43:47,659 DEBUG (MainThread) [root] /sbin/ip
>> link
>> > add name dummy_Afi2m type dummy (cwd None) (cmdutils:150)
>> > 00:04:37.294 2018-02-08 11:43:47,675 DEBUG (MainThread) [root] SUCCESS:
>> >  = '';  = 0 (cmdutils:158)
>> > 00:04:37.295 2018-02-08 11:43:47,678 DEBUG (netlink/events) [root] START
>> > thread 
>> (func=> > method Monitor._scan of > > 0x7fdcb6687290>>, args=(), kwargs={}) (concurrent:192)
>> > 00:04:37.296 2018-02-08 11:43:47,680 DEBUG (MainThread) [root] /sbin/ip
>> link
>> > set dev dummy_Afi2m up (cwd None) (cmdutils:150)
>> > 00:04:37.297 2018-02-08 11:43:47,700 DEBUG (MainThread) [root] SUCCESS:
>> >  = '';  = 0 (cmdutils:158)
>> > 00:04:37.298 2018-02-08 11:43:47,704 DEBUG (netlink/events) [root]
>> FINISH
>> > thread 
>> > (concurrent:195)
>> > 00:04:37.298 2018-02-08 11:43:47,706 DEBUG (MainThread) [root] lshw
>> -json
>> > -disable usb -disable pcmcia -disable isapnp -disable ide -disable scsi
>> > -disable dmi -disable memory -disable cpuinfo (cwd None) (cmdutils:150)
>> > 00:04:37.300 2018-02-08 11:43:47,866 DEBUG (MainThread) [root] SUCCESS:
>> >  = '';  = 0 (cmdutils:158)
>> > 00:04:37.300 2018-02-08 11:43:47,868 DEBUG (MainThread)

Re: [ovirt-devel] [25-1-18] [ OST Failure Report] [oVirt Master (vdsm)] [post-002_bootstrap]

[Edward Haas]

The revert was merged.

On Thu, Jan 25, 2018 at 12:32 PM, Daniel Belenky 
wrote:

> Have you tried running OST with rpms from the suspected patch to reproduce?
>

I meant reproducing it manually, not though OST.


> On Thu, Jan 25, 2018 at 12:24 PM Edward Haas  wrote:
>
>> We have two options, a revert or a fix:
>> Revert: https://gerrit.ovirt.org/#/c/86789/
>> Fix: https://gerrit.ovirt.org/#/c/86785/
>>
>> We are not sure about the fix because we cannot reproduce the problem
>> manually.
>>
>>
>> On Thu, Jan 25, 2018 at 10:45 AM, Eyal Edri  wrote:
>>
>>> Once you have RPMs, you can run the upgrade suite from the manual job.
>>>
>>> On Thu, Jan 25, 2018 at 10:43 AM, Edward Haas  wrote:
>>>
>>>> Can we test if this one fixes this problem?
>>>> https://gerrit.ovirt.org/#/c/86781
>>>>
>>>> On Thu, Jan 25, 2018 at 10:00 AM, Eyal Edri  wrote:
>>>>
>>>>> Indeed, the patch looks relevant,
>>>>> Dan, can we revert it or send a fix ASAP to avoid building up a large
>>>>> queue?
>>>>>
>>>>> On Thu, Jan 25, 2018 at 9:29 AM, Daniel Belenky 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We failed to setup host in OST upgrade from 4.1 to master suite.
>>>>>> Please note that the upgrade suite installs 4.1 engine, then upgrades
>>>>>> it to master and then tries to set up a host.
>>>>>>
>>>>>> *Links:*
>>>>>>
>>>>>>1. Link to failed job
>>>>>>
>>>>>> <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5093/artifact/exported-artifacts/upgrade-from-release-suit-master-el7/test_logs/upgrade-from-release-suite-master/post-002_bootstrap.py/>
>>>>>>2. Suspected patch: Gerrit 86474/33
>>>>>><https://gerrit.ovirt.org/#/c/86474/33>
>>>>>>
>>>>>> *Error snippet from engine.log (engine):*
>>>>>>
>>>>>> 2018-01-24 15:13:20,257-05 ERROR 
>>>>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>>>>>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An 
>>>>>> error has occurred during installation of Host 
>>>>>> lago-upgrade-from-release-suite-master-host0: Failed to execute stage 
>>>>>> 'Closing up': Failed to start service 'vdsmd'.
>>>>>> 2018-01-24 15:13:20,301-05 INFO  
>>>>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>>>>>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), 
>>>>>> Installing Host lago-upgrade-from-release-suite-master-host0. Stage: 
>>>>>> Clean up.
>>>>>> 2018-01-24 15:13:20,304-05 INFO  
>>>>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>>>>>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), 
>>>>>> Installing Host lago-upgrade-from-release-suite-master-host0. Stage: 
>>>>>> Pre-termination.
>>>>>> 2018-01-24 15:13:20,332-05 INFO  
>>>>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>>>>>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), 
>>>>>> Installing Host lago-upgrade-from-release-suite-master-host0. Retrieving 
>>>>>> installation logs to: 
>>>>>> '/var/log/ovirt-engine/host-deploy/ovirt-host-deploy-20180124151320-lago-upgrade-from-release-suite-master-host0-34609a2f.log'.
>>>>>> 2018-01-24 15:13:29,227-05 INFO  
>>>>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>>>>>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), 
>>>>>> Installing Host lago-upgrade-from-release-suite-master-host0. Stage: 
>>>>>> Termination.
>>>>>> 2018-01-24 15:13:29,321-05 ERROR 
>>>>>> [org.ovirt.engine.core.uutils.ssh.SSHDialog] 
>>>>>> (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] SSH error running 
>>>>>> command root@lago-upgrade-from-release-suite-master-host0:'umask 0077; 
>>>>>> MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t ovirt-XX)"; trap 
>>>>>> &q

Re: [ovirt-devel] [25-1-18] [ OST Failure Report] [oVirt Master (vdsm)] [post-002_bootstrap]

[Edward Haas]

We have two options, a revert or a fix:
Revert: https://gerrit.ovirt.org/#/c/86789/
Fix: https://gerrit.ovirt.org/#/c/86785/

We are not sure about the fix because we cannot reproduce the problem
manually.


On Thu, Jan 25, 2018 at 10:45 AM, Eyal Edri  wrote:

> Once you have RPMs, you can run the upgrade suite from the manual job.
>
> On Thu, Jan 25, 2018 at 10:43 AM, Edward Haas  wrote:
>
>> Can we test if this one fixes this problem?
>> https://gerrit.ovirt.org/#/c/86781
>>
>> On Thu, Jan 25, 2018 at 10:00 AM, Eyal Edri  wrote:
>>
>>> Indeed, the patch looks relevant,
>>> Dan, can we revert it or send a fix ASAP to avoid building up a large
>>> queue?
>>>
>>> On Thu, Jan 25, 2018 at 9:29 AM, Daniel Belenky 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> We failed to setup host in OST upgrade from 4.1 to master suite.
>>>> Please note that the upgrade suite installs 4.1 engine, then upgrades
>>>> it to master and then tries to set up a host.
>>>>
>>>> *Links:*
>>>>
>>>>1. Link to failed job
>>>>
>>>> <http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5093/artifact/exported-artifacts/upgrade-from-release-suit-master-el7/test_logs/upgrade-from-release-suite-master/post-002_bootstrap.py/>
>>>>2. Suspected patch: Gerrit 86474/33
>>>><https://gerrit.ovirt.org/#/c/86474/33>
>>>>
>>>> *Error snippet from engine.log (engine):*
>>>>
>>>> 2018-01-24 15:13:20,257-05 ERROR 
>>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>>>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An 
>>>> error has occurred during installation of Host 
>>>> lago-upgrade-from-release-suite-master-host0: Failed to execute stage 
>>>> 'Closing up': Failed to start service 'vdsmd'.
>>>> 2018-01-24 15:13:20,301-05 INFO  
>>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>>>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing 
>>>> Host lago-upgrade-from-release-suite-master-host0. Stage: Clean up.
>>>> 2018-01-24 15:13:20,304-05 INFO  
>>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>>>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing 
>>>> Host lago-upgrade-from-release-suite-master-host0. Stage: Pre-termination.
>>>> 2018-01-24 15:13:20,332-05 INFO  
>>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>>>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing 
>>>> Host lago-upgrade-from-release-suite-master-host0. Retrieving installation 
>>>> logs to: 
>>>> '/var/log/ovirt-engine/host-deploy/ovirt-host-deploy-20180124151320-lago-upgrade-from-release-suite-master-host0-34609a2f.log'.
>>>> 2018-01-24 15:13:29,227-05 INFO  
>>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>>>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing 
>>>> Host lago-upgrade-from-release-suite-master-host0. Stage: Termination.
>>>> 2018-01-24 15:13:29,321-05 ERROR 
>>>> [org.ovirt.engine.core.uutils.ssh.SSHDialog] 
>>>> (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] SSH error running 
>>>> command root@lago-upgrade-from-release-suite-master-host0:'umask 0077; 
>>>> MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t ovirt-XX)"; trap 
>>>> "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > 
>>>> /dev/null 2>&1" 0; tar --warning=no-timestamp -C "${MYTMP}" -x &&  
>>>> "${MYTMP}"/ovirt-host-deploy DIALOG/dialect=str:machine 
>>>> DIALOG/customization=bool:True': IOException: Command returned failure 
>>>> code 1 during SSH session 
>>>> 'root@lago-upgrade-from-release-suite-master-host0'
>>>> 2018-01-24 15:13:29,322-05 ERROR 
>>>> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] 
>>>> (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] Error during host 
>>>> lago-upgrade-from-release-suite-master-host0 install
>>>> 2018-01-24 15:13:29,324-05 ERROR 
>>>> [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] 
>>&g

Re: [ovirt-devel] [25-1-18] [ OST Failure Report] [oVirt Master (vdsm)] [post-002_bootstrap]

[Edward Haas]

Can we test if this one fixes this problem?
https://gerrit.ovirt.org/#/c/86781

On Thu, Jan 25, 2018 at 10:00 AM, Eyal Edri  wrote:

> Indeed, the patch looks relevant,
> Dan, can we revert it or send a fix ASAP to avoid building up a large
> queue?
>
> On Thu, Jan 25, 2018 at 9:29 AM, Daniel Belenky 
> wrote:
>
>> Hi,
>>
>> We failed to setup host in OST upgrade from 4.1 to master suite.
>> Please note that the upgrade suite installs 4.1 engine, then upgrades it
>> to master and then tries to set up a host.
>>
>> *Links:*
>>
>>1. Link to failed job
>>
>> 
>>2. Suspected patch: Gerrit 86474/33
>>
>>
>> *Error snippet from engine.log (engine):*
>>
>> 2018-01-24 15:13:20,257-05 ERROR 
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS_ERROR(511), An 
>> error has occurred during installation of Host 
>> lago-upgrade-from-release-suite-master-host0: Failed to execute stage 
>> 'Closing up': Failed to start service 'vdsmd'.
>> 2018-01-24 15:13:20,301-05 INFO  
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing 
>> Host lago-upgrade-from-release-suite-master-host0. Stage: Clean up.
>> 2018-01-24 15:13:20,304-05 INFO  
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing 
>> Host lago-upgrade-from-release-suite-master-host0. Stage: Pre-termination.
>> 2018-01-24 15:13:20,332-05 INFO  
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing 
>> Host lago-upgrade-from-release-suite-master-host0. Retrieving installation 
>> logs to: 
>> '/var/log/ovirt-engine/host-deploy/ovirt-host-deploy-20180124151320-lago-upgrade-from-release-suite-master-host0-34609a2f.log'.
>> 2018-01-24 15:13:29,227-05 INFO  
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>> (VdsDeploy) [34609a2f] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509), Installing 
>> Host lago-upgrade-from-release-suite-master-host0. Stage: Termination.
>> 2018-01-24 15:13:29,321-05 ERROR 
>> [org.ovirt.engine.core.uutils.ssh.SSHDialog] 
>> (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] SSH error running 
>> command root@lago-upgrade-from-release-suite-master-host0:'umask 0077; 
>> MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t ovirt-XX)"; trap 
>> "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > 
>> /dev/null 2>&1" 0; tar --warning=no-timestamp -C "${MYTMP}" -x &&  
>> "${MYTMP}"/ovirt-host-deploy DIALOG/dialect=str:machine 
>> DIALOG/customization=bool:True': IOException: Command returned failure code 
>> 1 during SSH session 'root@lago-upgrade-from-release-suite-master-host0'
>> 2018-01-24 15:13:29,322-05 ERROR 
>> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] 
>> (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] Error during host 
>> lago-upgrade-from-release-suite-master-host0 install
>> 2018-01-24 15:13:29,324-05 ERROR 
>> [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] 
>> (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] Host installation 
>> failed for host '4d681c3b-e8db-4a71-b5e3-0db096e3ae9c', 
>> 'lago-upgrade-from-release-suite-master-host0': Command returned failure 
>> code 1 during SSH session 'root@lago-upgrade-from-release-suite-master-host0'
>> 2018-01-24 15:13:29,330-05 INFO  
>> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] 
>> (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] START, 
>> SetVdsStatusVDSCommand(HostName = 
>> lago-upgrade-from-release-suite-master-host0, 
>> SetVdsStatusVDSCommandParameters:{hostId='4d681c3b-e8db-4a71-b5e3-0db096e3ae9c',
>>  status='InstallFailed', nonOperationalReason='NONE', 
>> stopSpmFailureLogged='false', maintenanceReason='null'}), log id: 5e6c4a3e
>> 2018-01-24 15:13:29,339-05 INFO  
>> [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] 
>> (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] FINISH, 
>> SetVdsStatusVDSCommand, log id: 5e6c4a3e
>> 2018-01-24 15:13:29,346-05 ERROR 
>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
>> (EE-ManagedThreadFactory-engine-Thread-1) [34609a2f] EVENT_ID: 
>> VDS_INSTALL_FAILED(505), Host lago-upgrade-from-release-suite-master-host0 
>> installation failed. Command returned failure code 1 during SSH session 
>> 'root@lago-upgrade-from-release-suite-master-host0'.
>>
>> *Error snippet from /var/log/messages (host0):*
>>
>> 15:13:19 host0 NetworkManager[580]:   (bondscan-Ncw7DP): new Bond 
>> device (carrier: OFF, drive

Re: [ovirt-devel] Subject: [ OST Failure Report ] [ oVirt Master ] [ Jan 15th 2018 ] [ 006_migrations.migrate_vm ]

[Edward Haas]

On Mon, Jan 15, 2018 at 5:13 PM, Dafna Ron  wrote:

> Hi,
>
> We had a failure in test 006_migrations.migrate_vm
> .
>
> the migration failed with reason "VMExists"
>
> Seems to be an issue which is caused by connectivity between engine and
> hosts.
> I remember this issue happening before a few weeks ago - is there a
> solution/bug for this issue?
>
>
>
> *Link and headline of suspected patches:
> https://gerrit.ovirt.org/#/c/86114/4 
> - net tests: Fix vlan creation name length in nettestlib*
>

This touched tests, not production code, so I do not think it is relevant.


>
> * Link to Job:*
>
>
>
>
> *http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4842/
> Link
> to all
> logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4842/artifact/
> (Relevant)
> error snippet from the log: *
>
>
>
>
>
>
>
>
>
> *vdsm dst:2018-01-15 06:47:03,355-0500 ERROR (jsonrpc/0) [api] FINISH
> create error=Virtual machine already exists (api:124)Traceback (most recent
> call last):  File "/usr/lib/python2.7/site-packages/vdsm/common/api.py",
> line 117, in methodret = func(*args, **kwargs)  File
> "/usr/lib/python2.7/site-packages/vdsm/API.py", line 180, in create
> raise exception.VMExists()VMExists: Virtual machine already exists*
>
>
> *vdsm src: 2018-01-15 06:47:03,359-0500 ERROR (migsrc/d17a2482) [virt.vm] *
> (vmId='d17a2482-4904-4cbc-8d13-3a3b7840782d') migration destination
> error: Virtual machine already exists (migration:290
>
>
> *)*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Engine: 2018-01-15 06:45:30,169-05 ERROR
> [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring]
> (EE-ManagedThreadFactory-engineScheduled-Thread-34) [] Failure to refresh
> host 'lago-basic-suite-master-host-0' runtime info:
> java.net.ConnectException: Connection refused2018-01-15 06:45:30,169-05
> DEBUG [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring]
> (EE-ManagedThreadFactory-engineScheduled-Thread-34) [] Exception:
> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
> java.net.ConnectException: Connection refusedat
> org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.createNetworkException(VdsBrokerCommand.java:159)
> [vdsbroker.jar:]at
> org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:122)
> [vdsbroker.jar:]at
> org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:73)
> [vdsbroker.jar:]at
> org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:33)
> [dal.jar:]at
> org.ovirt.engine.core.vdsbroker.vdsbroker.DefaultVdsCommandExecutor.execute(DefaultVdsCommandExecutor.java:14)
> [vdsbroker.jar:]at
> org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:387)
> [vdsbroker.jar:]at
> org.ovirt.engine.core.vdsbroker.ResourceManager$Proxy$_$$_WeldSubclass.runVdsCommand$$super(Unknown
> Source) [vdsbroker.jar:]at
> sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source)
> [:1.8.0_151]at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.8.0_151]at
> java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_151]
> at
> org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:49)
> [weld-core-impl-2.4.3.Final.jar:2.4.3.Final]at
> org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:77)
> [weld-core-impl-2.4.3.Final.jar:2.4.3.Final]at
> org.ovirt.engine.core.common.di.interceptor.LoggingInterceptor.apply(LoggingInterceptor.java:12)
> [common.jar:]at
> sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source)
> [:1.8.0_151]at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.8.0_151]at
> java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_151]
> at
> org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> [weld-core-impl-2.4.3.Final.jar:2.4.3.Final]at
> org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84)
> [weld-core-impl-2.4.3.Final.jar:2.4.3.Final]at
> org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72)
> [weld-core-impl-2.4.3.Final.jar:2.4.3.Final]at
> org.jboss.weld.interceptor.proxy.InterceptorMethodH

Re: [ovirt-devel] vdsm stable branch maitainership

[Edward Haas]

+1

On Tue, Jan 9, 2018 at 2:01 PM, Yaniv Bronheim  wrote:

> +1
>
> On Tue, Jan 9, 2018 at 1:47 PM Piotr Kliczewski 
> wrote:
>
>> +1
>>
>> On Tue, Jan 9, 2018 at 12:43 PM, Dan Kenigsberg 
>> wrote:
>>
>>> Hello,
>>>
>>> I would like to nominate Milan Zamazal and Petr Horacek as maintainers
>>> of vdsm stable branches. This job requires understanding of vdsm
>>> packaging and code, a lot of attention to details and awareness of the
>>> requirements of other components and teams.
>>>
>>> I believe that both Milan and Petr have these qualities. I am certain
>>> they would work in responsive caution when merging and tagging patches
>>> to the stable branches.
>>>
>>> vdsm maintainers, please confirm if you approve.
>>>
>>> Regards,
>>> Dan.
>>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> --
> Yaniv Bronhaim.
>
> ___
> 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

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 24/12/2017 ] [use_ovn_provider]

[Edward Haas]

On Wed, Dec 27, 2017 at 12:53 PM, Dan Kenigsberg  wrote:

> On Wed, Dec 27, 2017 at 12:34 PM, Barak Korren  wrote:
> > On 25 December 2017 at 14:14, Dan Kenigsberg  wrote:
> >> On Mon, Dec 25, 2017 at 2:09 PM, Dominik Holler 
> wrote:
> >>> A helpful hint is in
> >>>
> >>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-
> tester/4492/artifact/exported-artifacts/basic-suit-master-
> el7/test_logs/basic-suite-master/post-098_ovirt_
> provider_ovn.py/lago-basic-suite-master-engine/_var_log/
> ovirt-engine/engine.log :
> >>> Caused by: org.jboss.resteasy.spi.ReaderException:
> org.codehaus.jackson.map.JsonMappingException: Can not construct instance
> of java.util.Calendar from String value '2017-12-27 13:19:51Z': not a valid
> representation (error: Can not parse date "2017-12-27 13:19:51Z": not
> compatible with any of standard forms ("-MM-dd'T'HH:mm:ss.SSSZ",
> "-MM-dd'T'HH:mm:ss.SSS'Z'", "EEE, dd MMM  HH:mm:ss zzz",
> "-MM-dd"))
> >>>  at [Source: org.jboss.resteasy.client.core.BaseClientResponse$
> InputStreamWrapper@72c184c5; line: 1, column: 23] (through reference
> chain: com.woorea.openstack.keystone.model.Access["token"]->com.
> woorea.openstack.keystone.model.Token["expires"])
> >>>
> >>>
> >>> This problem was introduced by
> >>> https://gerrit.ovirt.org/#/c/85702/
> >>>
> >>> I created a fix:
> >>> https://gerrit.ovirt.org/85734
> >>
> >> Thanks for the quick fix.
> >>
> >> Is the new format accpetable to other users of the keystone-like API
> >> (such at the neutron cli)?
> >
> > It seems the fix patch itself failed as well:
> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4539/
> >
> > The failed test is: 006_migrations.prepare_migration_attachments_ipv6
> >
> > It seems engine has lost the ability to talk to the host.
> >
> > Logs are here:
> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-
> tester/4539/artifact/exported-artifacts/basic-suit-master-
> el7/test_logs/basic-suite-master/post-006_migrations.py/
>
> The error seems unrelated to the patch, since - as you say - the error
> is about host networking, long before OVN got involved.
>
> I see that
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-
> tester/4539/artifact/exported-artifacts/basic-suit-master-
> el7/test_logs/basic-suite-master/post-006_migrations.py/
> lago-basic-suite-master-host-0/_var_log/vdsm/supervdsm.log/*view*/
>
> has a worrying failure to ifup a bridge, which might be more related
>
> ifup/oncae8adf7ba944::ERROR::2017-12-27
> 05:03:06,001::concurrent::201::root::(run) FINISH thread
>  failed
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/vdsm/common/concurrent.py",
> line 194, in run
> ret = func(*args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/vdsm/network/
> configurators/ifcfg.py",
> line 925, in _exec_ifup
> _exec_ifup_by_name(iface.name, cgroup)
>   File "/usr/lib/python2.7/site-packages/vdsm/network/
> configurators/ifcfg.py",
> line 911, in _exec_ifup_by_name
> raise ConfigNetworkError(ERR_FAILED_IFUP, out[-1] if out else '')
> ConfigNetworkError: (29, '\n')
>

Does not seem to be a problem, it is an outcome of an ancient command on an
device that does not exist anymore.
We are not cleaning up all the spawned threads at the end of a transaction,
so we see such things from time to time.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ovirt-users] ovirt 4.2 host not compatible

[Edward Haas]

On Fri, Dec 22, 2017 at 11:09 PM, Paul Dyer  wrote:

> It seems that I am using net_persistence = ifcfg, and that I have lost the
> definitions for the logical networks.
>

Could you please share with us when and in what manner you lost these
definitions?
Is it re-creatable?


>
> I have recovered these, and was able to do setup logical networks.
>
> It is all working now.
>
> Paul
>
> On Fri, Dec 22, 2017 at 1:46 PM, Paul Dyer  wrote:
>
>> My setup is RHEL 7.4, with the host separate from the engine.
>>
>> The ovirt-release42 rpm was added to the engine host, but not to the
>> virtualization host.   The vhost was still running v4.1 rpms.   I installed
>> ovirt-release42 on the vhost, then updated the rest of the rpms with "yum
>> update".I am still getting an error on activation of the vhost...
>>
>>  Host parasol does not comply with the cluster Intel networks, the
>> following networks are missing on host: 'data30,data40,ovirtmgmt'
>>
>> It seems like the networks bridges are not there anymore??
>>
>> Paul
>>
>>
>>
>> On Fri, Dec 22, 2017 at 12:46 PM, Paul Dyer  wrote:
>>
>>> Hi,
>>>
>>> I have upgraded to ovirt 4.2 without issue.   But I cannot find a way to
>>> upgrade the host compatibility in the new OVirt Manager.
>>>
>>> I get this error when activiating the host...
>>>
>>> host parasol is compatible with versions (3.6,4.0,4.1) and cannot join
>>> Cluster Intel which is set to version 4.2.
>>>
>>> Thanks,
>>> Paul
>>>
>>>
>>> --
>>> Paul Dyer,
>>> Mercury Consulting Group, RHCE
>>> 504-302-8750 <(504)%20302-8750>
>>>
>>
>>
>>
>> --
>> Paul Dyer,
>> Mercury Consulting Group, RHCE
>> 504-302-8750 <(504)%20302-8750>
>>
>
>
>
> --
> Paul Dyer,
> Mercury Consulting Group, RHCE
> 504-302-8750 <(504)%20302-8750>
>
> ___
> Users mailing list
> us...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt CI now supports Fedora 27 and Fedora Rawhide

[Edward Haas]

On Fri, Nov 24, 2017 at 1:46 PM, Barak Korren  wrote:

> On 24 November 2017 at 13:27, Dan Kenigsberg  wrote:
> >
> >
> >> On Nov 23, 2017 17:23, "Nir Soffer"  wrote:
> >>
> >>
> >> The job is successful,
> >
> >
> > That's an oversimplification.
> > http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-
> x86_64/174/consoleText
> > fails with another dependency
> >
> >   - nothing provides mom >= 0.5.8 needed by
> > vdsm-4.20.8-1.git383bc1031.fc27.x86_64
> >   - nothing provides mom >= 0.5.8 needed by
> > vdsm-4.20.8-3.gita9ee9c65f.fc27.x86_64
> >   - nothing provides python-argparse needed by
> > vdsm-4.18.999-444.git0bb7717.fc27.x86_64
> >
> >
> > some tests or maybe the code they test need work.
> > This is why we have skipif/xfail and broken_on_ci.
>
> So why is this passing:
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/180/


See https://gerrit.ovirt.org/#/q/topic:net-isolation+status:open
All failures are due to this mom dependency.


>
>
> --
> 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

Re: [ovirt-devel] oVirt CI now supports Fedora 27 and Fedora Rawhide

[Edward Haas]

On Fri, Nov 24, 2017 at 3:10 PM, Francesco Romani 
wrote:

>
> On 11/23/2017 03:55 PM, Dan Kenigsberg wrote:
>
>
> Please make sure the few failing network tests are not breaking the build.
>
> It's probably time to mark the tests that use loseup as broken-on-jenkins
>
> ERROR: Tests mkimage.injectFilesToFs creating an image and checking its
> --
> Traceback (most recent call last):
>   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/testlib.py",
> line 143, in wrapper
> return f(self, *args)
>   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/testValidation.py",
> line 191, in wrapper
> return f(*args, **kwargs)
>   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/mkimage_test.py",
> line 176, in test_injectFilesToFs
> mkimage.injectFilesToFs(floppy, self.files, fstype)
>   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/lib/vdsm/mkimage.py",
> line 112, in injectFilesToFs
> m.mount(mntOpts='loop', vfstype=fstype)
>   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/lib/vdsm/storage/mount.py",
> line 208, in mount
> cgroup=cgroup)
>   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/lib/vdsm/storage/mount.py",
> line 278, in _mount
> _runcmd(cmd)
>   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/lib/vdsm/storage/mount.py",
> line 306, in _runcmd
> raise MountError(rc, ";".join((out, err)))
> MountError: (32, ';mount:
> /tmp/vdsm-mkimage-testspahtvm/images/vmId_inject.7301b08f8c0dc496bedd25577dbddbd8.img:
> failed to setup loop device: No such file or directory\n')
>
>
>
> This test may need some attention too:
>

https://gerrit.ovirt.org/#/c/84640 should handle it.


>
> *11:05:09* *11:05:09* 
> ==*11:05:09*
>  FAIL: test_multiple_vlans (network.tc_test.TestConfigureOutbound)*11:05:09* 
> --*11:05:09*
>  Traceback (most recent call last):*11:05:09*   File 
> "/usr/lib/python2.7/site-packages/mock/mock.py", line 1305, in 
> patched*11:05:09* return func(*args, **keywargs)*11:05:09*   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_64/vdsm/tests/network/tc_test.py",
>  line 459, in test_multiple_vlans*11:05:09* 
> self._analyse_qos_and_general_assertions()*11:05:09*   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_64/vdsm/tests/network/tc_test.py",
>  line 531, in _analyse_qos_and_general_assertions*11:05:09* 
> tc_filters.tagged_filters)*11:05:09*   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_64/vdsm/tests/network/tc_test.py",
>  line 579, in _assertions_on_filters*11:05:09* 
> self.assertEqual(len(untagged_filters), 1)*11:05:09* AssertionError: 0 != 
> 1*11:05:09*  >> begin captured logging << 
> 
>
>
> *11:05:09*  >> begin captured logging << 
> *11:05:09* 2017-11-24 11:04:39,898 DEBUG (MainThread) 
> [root] /sbin/ip link add name dummy_XHoki type dummy (cwd None) 
> (cmdutils:133)*11:05:09* 2017-11-24 11:04:39,906 DEBUG (MainThread) [root] 
> SUCCESS:  = '';  = 0 (cmdutils:141)*11:05:09* 2017-11-24 
> 11:04:39,907 DEBUG (MainThread) [root] /sbin/ip link set dev dummy_XHoki up 
> (cwd None) (cmdutils:133)*11:05:09* 2017-11-24 11:04:39,916 DEBUG 
> (MainThread) [root] SUCCESS:  = '';  = 0 (cmdutils:141)*11:05:09* 
> 2017-11-24 11:04:39,917 DEBUG (MainThread) [root] /sbin/ip link add link 
> dummy_XHoki name dummy_XHoki.16 type vlan id 16 (cwd None) 
> (cmdutils:133)*11:05:09* 2017-11-24 11:04:39,927 DEBUG (MainThread) [root] 
> SUCCESS:  = '';  = 0 (cmdutils:141)*11:05:09* 2017-11-24 
> 11:04:39,928 DEBUG (MainThread) [root] /sbin/ip link set dev dummy_XHoki.16 
> up (cwd None) (cmdutils:133)*11:05:09* 2017-11-24 11:04:39,938 DEBUG 
> (MainThread) [root] SUCCESS:  = '';  = 0 (cmdutils:141)*11:05:09* 
> 2017-11-24 11:04:39,939 DEBUG (MainThread) [root] /sbin/ip link add link 
> dummy_XHoki name dummy_XHoki.17 type vlan id 17 (cwd None) 
> (cmdutils:133)*11:05:09* 2017-11-24 11:04:39,947 DEBUG (MainThread) [root] 
> SUCCESS:  = '';  = 0 (cmdutils:141)*11:05:09* 2017-11-24 
> 11:04:39,948 DEBUG (MainThread) [root] /sbin/ip link set dev dummy_XHoki.17 
> up (cwd None) (cmdutils:133)*11:05:09* 2017-11-24 11:04:39,958 DEBUG 
> (MainThread) [root] SUCCESS:  = '';  = 0 (cmdutils:141)*11:05:09* 
> 2017-11-24 11:04:39,959 DEBUG (MainThread) [root] /sbin/tc qdisc show dev 
> dummy_XHoki (cwd None) (cmdutils:133)*11:05:09* 2017-11-24 11:04:39,967 DEBUG 
> (MainThread) [root] SUCCESS:  = '';  = 0 (cmdutils:141)*11:05:09* 
> 2017-11-24 11:04:39,967 DEBUG (MainThread) [root] /sbin/tc qdisc del dev 
> dummy_XHoki root (cwd None) (cmdutils:133)*11:05:09*

Re: [ovirt-devel] oVirt CI now supports Fedora 27 and Fedora Rawhide

[Edward Haas]

Per what I see, all CI jobs on vdsm/fc27 fail.
This is the second time this week, please consider reverting.

We should try to avoid such changed before the weekend.

Thanks,
Edy.


On Thu, Nov 23, 2017 at 1:20 PM, Nir Soffer  wrote:

>
>
> On Thu, Nov 23, 2017 at 1:03 PM Barak Korren  wrote:
>
>> On 23 November 2017 at 12:49, Nir Soffer  wrote:
>> > On Thu, Nov 23, 2017 at 12:43 PM Barak Korren 
>> wrote:
>> >>
>> >> On 23 November 2017 at 12:31, Nir Soffer  wrote:
>> >> > On Thu, Nov 23, 2017 at 12:25 PM Barak Korren 
>> >> > wrote:
>> >> I suspect this may have to do with the host you're running on, the
>> >> yum/dnf switch over is giving us a hard time...
>> >>
>> >> What distro are you using locally?
>> >
>> >
>> > Fedora 25. What do we use in the CI?
>> >
>>
>> We have everything from el7 to fc26, and selection is pretty random.
>> It does try reuse the same slave consistently once the selection is made.
>>
>> Need to check what the failing runs ran on, can you share a link?
>>
>
> We don't have failures in the ci yet since we fcraw is not enable yet :-)
>
>
>>
>> --
>> 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

[ovirt-devel] Unable to run "make check" on master with an updated Centos7

[Edward Haas]

Hello,

After updating my Centos7 VM, the unit tests are failing on check_imports.
Some kind of recursion.

https://paste.fedoraproject.org/paste/lcjYudT50AJDLJnw9SH3vw

I have not seen this on CI.
Any ideas?

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

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 2017-08-30 ] [add_hosts]

[Edward Haas]

On Wed, Aug 30, 2017 at 2:31 PM, Dominik Holler  wrote:

> On Wed, 30 Aug 2017 14:18:49 +0300
> Dan Kenigsberg  wrote:
>
> > On Wed, Aug 30, 2017 at 1:40 PM, Barak Korren 
> > wrote:
> > > Test failed: [ 002_bootstrap.add_hosts ]
> > >
> > > Link to suspected patches:
> > >
> > > We suspect this is due to change to LLDPAD in upstream CentOS repos.
> > > We can't tell the exact point it was introduced because other
> > > ovirt-engine regressions introduced too much noise into the system.
> > >
> > > It also seems that the failure is not 100% reproducible sine we have
> > > runs that do not encounter it.
> > >
> > > Link to Job:
> > > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/2151
> > >
> > > (This job checked a specific patch to ovirt-log-collector but
> > > failure seems unrelated, and also happens on vanille 'tested' repo
> > > right now).
> > >
> > > Link to all logs:
> > > VDSM logs seem to be most relevant here:
> > >
> > > http://jenkins.ovirt.org/job/ovirt-master_change-queue-
> tester/2151/artifact/exported-artifacts/basic-suit-master-
> el7/test_logs/basic-suite-master/post-002_bootstrap.py/
> lago-basic-suite-master-host-0/_var_log/vdsm/
> > >
> > > Error snippet from log:
> > >
> > > - From VDSM logs (note it exists very quickly):
> > >
> > > 
> > >
> > > 2017-08-30 05:55:52,208-0400 INFO  (MainThread) [vds] (PID: 4594) I
> > > am the actual vdsm 4.20.2-133.git0ce4485.el7.centos
> > > lago-basic-suite-master-host-0 (3.10.0-514.2.2.el7.x86_64)
> > > (vdsmd:148) 2017-08-30 05:55:52,209-0400 INFO  (MainThread) [vds]
> > > VDSM will run with cpu affinity: frozenset([1]) (vdsmd:254)
> > > 2017-08-30 05:55:52,253-0400 INFO  (MainThread) [storage.check]
> > > Starting check service (check:92)
> > > 2017-08-30 05:55:52,257-0400 INFO  (MainThread) [storage.Dispatcher]
> > > Starting StorageDispatcher... (dispatcher:48)
> > > 2017-08-30 05:55:52,257-0400 INFO  (check/loop) [storage.asyncevent]
> > > Starting 
> > > (asyncevent:125)
> > > 2017-08-30 05:55:52,288-0400 INFO  (MainThread) [vdsm.api] START
> > > registerDomainStateChangeCallback(callbackFunc= > > object at 0x2b47b50>) from=internal,
> > > task_id=2cebe9ef-358e-47d7-81a6-8c4b54b9cd6d (api:46)
> > > 2017-08-30 05:55:52,288-0400 INFO  (MainThread) [vdsm.api] FINISH
> > > registerDomainStateChangeCallback return=None from=internal,
> > > task_id=2cebe9ef-358e-47d7-81a6-8c4b54b9cd6d (api:52)
> > > 2017-08-30 05:55:52,288-0400 INFO  (MainThread) [MOM] Preparing MOM
> > > interface (momIF:53)
> > > 2017-08-30 05:55:52,289-0400 INFO  (MainThread) [MOM] Using named
> > > unix socket /var/run/vdsm/mom-vdsm.sock (momIF:62)
> > > 2017-08-30 05:55:52,289-0400 INFO  (MainThread) [root] Unregistering
> > > all secrets (secret:91)
> > > 2017-08-30 05:55:52,307-0400 INFO  (MainThread) [vds] Setting
> > > channels' timeout to 30 seconds. (vmchannels:221)
> > > 2017-08-30 05:55:52,309-0400 INFO  (vmrecovery) [vds] recovery:
> > > completed in 0s (clientIF:516)
> > > 2017-08-30 05:55:52,310-0400 INFO  (MainThread)
> > > [vds.MultiProtocolAcceptor] Listening at :::54321
> > > (protocoldetector:196)
> > > 2017-08-30 05:55:52,496-0400 INFO  (http) [vds] Server running
> > > (http:58) 2017-08-30 05:55:52,742-0400 INFO  (periodic/1)
> > > [vdsm.api] START repoStats(domains=()) from=internal,
> > > task_id=85768015-8ecb-48e3-9307-f671bfc33c65 (api:46)
> > > 2017-08-30 05:55:52,743-0400 INFO  (periodic/1) [vdsm.api] FINISH
> > > repoStats return={} from=internal,
> > > task_id=85768015-8ecb-48e3-9307-f671bfc33c65 (api:52)
> > > 2017-08-30 05:55:52,743-0400 WARN  (periodic/1) [throttled] MOM not
> > > available. (throttledlog:103)
> > > 2017-08-30 05:55:52,744-0400 WARN  (periodic/1) [throttled] MOM not
> > > available, KSM stats will be missing. (throttledlog:103)
> > > 2017-08-30 05:55:55,043-0400 INFO  (MainThread) [vds] Received
> > > signal 15, shutting down (vdsmd:67)
> > > 2017-08-30 05:55:55,045-0400 INFO  (MainThread)
> > > [jsonrpc.JsonRpcServer] Stopping JsonRPC Server (__init__:759)
> > > 2017-08-30 05:55:55,049-0400 INFO  (MainThread) [vds] Stopping http
> > > server (http:79)
> > > 2017-08-30 05:55:55,049-0400 INFO  (http) [vds] Server stopped
> > > (http:69) 2017-08-30 05:55:55,050-0400 INFO  (MainThread) [root]
> > > Unregistering all secrets (secret:91)
> > > 2017-08-30 05:55:55,052-0400 INFO  (MainThread) [vdsm.api] START
> > > prepareForShutdown(options=None) from=internal,
> > > task_id=ffde5caa-fa44-49ab-bdd1-df81519680a3 (api:46)
> > > 2017-08-30 05:55:55,089-0400 INFO  (MainThread) [storage.Monitor]
> > > Shutting down domain monitors (monitor:222)
> > > 2017-08-30 05:55:55,090-0400 INFO  (MainThread) [storage.check]
> > > Stopping check service (check:105)
> > > 2017-08-30 05:55:55,090-0400 INFO  (check/loop) [storage.asyncevent]
> > > Stopping 
> > > (asyncevent:220)
> > > 2017-08-30 05:55:55,090-0400 INFO  (MainThread) [vdsm.api] FINISH
> > > prepareForShutdown return=None from=internal,
> > > task_id=ffde5caa-fa44-49ab-bdd1-d

Re: [ovirt-devel] OST: libvirt: error : internal error: Check the host setup: enabling IPv6 forwarding with RA routes

[Edward Haas]

On Thu, Aug 10, 2017 at 3:13 PM, Milan Zamazal  wrote:

> Eyal Edri  writes:
>
> > Adding also lago-devel.
> > Eddy, isn't it the same issue I had on Fedora 26?
>

I do not recall the details, but this one seems very specific, telling
exactly what the problem is.


> The following command resolved the problem on my machine:
>
>   echo 2 > /proc/sys/net/ipv6/conf/enp0s25/accept_ra
>
> (Thanks to Petr Horáček for the advice.)
>
> > On Thu, Aug 10, 2017 at 2:32 PM, Milan Zamazal 
> wrote:
> >
> >> Hi, I get the following error when I try to run OST, I think since I've
> >> upgraded my computer to RHEL 7.4 recently:
> >>
> >>   + lago start
> >>   @ Start Prefix:
> >> # Start nets:
> >>   * Create network lago-basic-suite-master-net-storage:
> >>   libvirt:  error : internal error: Check the host setup: enabling IPv6
> >> forwarding with RA routes without accept_ra set to 2 is likely to cause
> >> routes loss. Interfaces to look at: enp0s25
> >>   * Create network lago-basic-suite-master-net-storage: ERROR (in
> >> 0:00:00)
> >> # Start nets: ERROR (in 0:00:00)
> >>   @ Start Prefix: ERROR (in 0:00:00)
> >>   Error occured, aborting
> >>   Traceback (most recent call last):
> >> File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 942, in
> main
> >>   cli_plugins[args.verb].do_run(args)
> >> File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line
> >> 184, in do_run
> >>   self._do_run(**vars(args))
> >> File "/usr/lib/python2.7/site-packages/lago/utils.py", line 501, in
> >> wrapper
> >>   return func(*args, **kwargs)
> >> File "/usr/lib/python2.7/site-packages/lago/utils.py", line 512, in
> >> wrapper
> >>   return func(*args, prefix=prefix, **kwargs)
> >> File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 265, in
> >> do_start
> >>   prefix.start(vm_names=vm_names)
> >> File "/usr/lib/python2.7/site-packages/lago/sdk_utils.py", line 50,
> >> in wrapped
> >>   return func(*args, **kwargs)
> >> File "/usr/lib/python2.7/site-packages/lago/prefix.py", line 1295,
> in
> >> start
> >>   self.virt_env.start(vm_names=vm_names)
> >> File "/usr/lib/python2.7/site-packages/lago/virt.py", line 342, in
> >> start
> >>   net.start()
> >> File "/usr/lib/python2.7/site-packages/lago/providers/
> libvirt/network.py",
> >> line 107, in start
> >>   net = self.libvirt_con.networkCreateXML(self._libvirt_xml())
> >> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4052, in
> >> networkCreateXML
> >>   if ret is None:raise libvirtError('virNetworkCreateXML() failed',
> >> conn=self)
> >>   libvirtError: internal error: Check the host setup: enabling IPv6
> >> forwarding with RA routes without accept_ra set to 2 is likely to cause
> >> routes loss. Interfaces to look at: enp0s25
> >>
> >> Do you have any idea how to fix / work around that and make OST running
> >> again?
> >>
> >> (Complete lago.log attached.)
> >>
> >> Thanks,
> >> Milan
> >>
> >>
> >> ___
> >> 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

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

[Edward Haas]

On Mon, Aug 7, 2017 at 5:26 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.
>

At this stage, the problem is not focus on security. If the usage is wrong
it will indeed break things, attacking that will require some more advance
means (but I am not sure we need it in a close system).


> 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.
>>
>> 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

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

[Edward Haas]

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

Re: [ovirt-devel] Unable to create ovirtmgmt network on node

[Edward Haas]

We are not suppose to add anything to block such things.

On Wed, Jul 19, 2017 at 2:56 PM, Shubhendu Tripathi 
wrote:

> Thanks Edy for the help. Could this related to some firewall issues or
> something?
> Any specific firewalld configuration required here?
>
> Regards,
> Shubhendu
>
> - Original Message -----
> From: "Edward Haas" 
> To: "Shubhendu Tripathi" 
> Cc: "engine-de...@ovirt.org" 
> Sent: Wednesday, July 19, 2017 5:13:34 PM
> Subject: Re: [ovirt-devel] Enable to create ovirtmgmt network on node
>
> Hi,
>
> Looks like you are not getting a response from the dhcp on VLAN 802  @em3
> interface.
>
> Thanks,
> Edy.
>
>
> On Wed, Jul 19, 2017 at 12:46 PM, Shubhendu Tripathi 
> wrote:
>
> > While creating a cluster, on one of the nodes creation of ovirtmgmt fails
> > and node is not in active state.
> > Looking at supervdsm.log, below are few snippets of errors-
> >
> > ===
> > MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> > 14:54:57,665::supervdsmServer::116::SuperVdsm.ServerCallback::(wrapper)
> > call setupNetworks with ({'ovirtmgmt': {'ipv6autoconf': False, 'nic':
> > 'em3', 'vlan': '802', 'mtu': 1500, 'switch': 'legacy', 'dhcpv6': False,
> > 'bridged': 'false', 'defaultRoute': True, 'bootproto': 'dhcp'}}, {},
> > {'connectivityCheck': 'true', 'connectivityTimeout': 120}) {}
> > MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,665::api::887::setupNetworks::(setupNetworks)
> > Setting up network according to configuration: networks:{'ovirtmgmt':
> > {'ipv6autoconf': False, 'nic': 'em3', 'vlan': '802', 'mtu': 1500,
> 'switch':
> > 'legacy', 'dhcpv6': False, 'bridged': 'false', 'defaultRoute': True,
> > 'bootproto': 'dhcp'}}, bondings:{}, options:{'connectivityCheck': 'true',
> > 'connectivityTimeout': 120}
> > MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> > 14:54:57,666::api::891::root::(setupNetworks) Validating configuration
> > MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31 14:54:57,670::
> > libvirtconnection::161::root::(get) trying to connect libvirt
> > MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
> > 14:54:57,690::netinfo::503::root::(_getNetInfo) Obtaining info for net
> > ovirtmgmt.
> > Traceback (most recent call last):
> >   File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 482, in
> > _getNetInfo
> > data.update({'ports': ports(iface),
> >   File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 187, in
> > ports
> > return os.listdir('/sys/class/net/' + bridge + '/brif')
> > OSError: [Errno 2] No such file or directory: '/sys/class/net/ovirtmgmt/
> > brif'
> > MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,708::api::901::setupNetworks::(setupNetworks)
> > Applying...
> > MainProcess|jsonrpc.Executor/6::INFO::2017-05-31 14:54:57,708::
> > netconfpersistence::73::root::(setBonding) Adding bond0({'nics': [],
> > 'options': 'mode=0'})
> > MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,709::api::926::setupNetworks::(setupNetworks)
> > Removing broken network 'ovirtmgmt'
> > MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
> > 14:54:57,717::netinfo::503::root::(_getNetInfo) Obtaining info for net
> > ovirtmgmt.
> > Traceback (most recent call last):
> >   File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 482, in
> > _getNetInfo
> > data.update({'ports': ports(iface),
> >   File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 187, in
> > ports
> > return os.listdir('/sys/class/net/' + bridge + '/brif')
> > OSError: [Errno 2] No such file or directory: '/sys/class/net/ovirtmgmt/
> > brif'
> > MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
> > 14:54:57,726::api::463::root::(_delNetwork) Removing network ovirtmgmt
> > with vlan=None, bonding=None, nics=[u'em3'],keep_bridge=False options={}
> > MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> > 14:54:57,727::ifcfg::335::root::(_atomicNetworkBackup) Backed up
> ovirtmgmt
> > MainProcess|jsonrpc.Executor/6::INFO:

Re: [ovirt-devel] Enable to create ovirtmgmt network on node

[Edward Haas]

Hi,

Looks like you are not getting a response from the dhcp on VLAN 802  @em3
interface.

Thanks,
Edy.


On Wed, Jul 19, 2017 at 12:46 PM, Shubhendu Tripathi 
wrote:

> While creating a cluster, on one of the nodes creation of ovirtmgmt fails
> and node is not in active state.
> Looking at supervdsm.log, below are few snippets of errors-
>
> ===
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,665::supervdsmServer::116::SuperVdsm.ServerCallback::(wrapper)
> call setupNetworks with ({'ovirtmgmt': {'ipv6autoconf': False, 'nic':
> 'em3', 'vlan': '802', 'mtu': 1500, 'switch': 'legacy', 'dhcpv6': False,
> 'bridged': 'false', 'defaultRoute': True, 'bootproto': 'dhcp'}}, {},
> {'connectivityCheck': 'true', 'connectivityTimeout': 120}) {}
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31 
> 14:54:57,665::api::887::setupNetworks::(setupNetworks)
> Setting up network according to configuration: networks:{'ovirtmgmt':
> {'ipv6autoconf': False, 'nic': 'em3', 'vlan': '802', 'mtu': 1500, 'switch':
> 'legacy', 'dhcpv6': False, 'bridged': 'false', 'defaultRoute': True,
> 'bootproto': 'dhcp'}}, bondings:{}, options:{'connectivityCheck': 'true',
> 'connectivityTimeout': 120}
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,666::api::891::root::(setupNetworks) Validating configuration
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31 14:54:57,670::
> libvirtconnection::161::root::(get) trying to connect libvirt
> MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
> 14:54:57,690::netinfo::503::root::(_getNetInfo) Obtaining info for net
> ovirtmgmt.
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 482, in
> _getNetInfo
> data.update({'ports': ports(iface),
>   File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 187, in
> ports
> return os.listdir('/sys/class/net/' + bridge + '/brif')
> OSError: [Errno 2] No such file or directory: '/sys/class/net/ovirtmgmt/
> brif'
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31 
> 14:54:57,708::api::901::setupNetworks::(setupNetworks)
> Applying...
> MainProcess|jsonrpc.Executor/6::INFO::2017-05-31 14:54:57,708::
> netconfpersistence::73::root::(setBonding) Adding bond0({'nics': [],
> 'options': 'mode=0'})
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31 
> 14:54:57,709::api::926::setupNetworks::(setupNetworks)
> Removing broken network 'ovirtmgmt'
> MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
> 14:54:57,717::netinfo::503::root::(_getNetInfo) Obtaining info for net
> ovirtmgmt.
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 482, in
> _getNetInfo
> data.update({'ports': ports(iface),
>   File "/usr/lib/python2.7/site-packages/vdsm/netinfo.py", line 187, in
> ports
> return os.listdir('/sys/class/net/' + bridge + '/brif')
> OSError: [Errno 2] No such file or directory: '/sys/class/net/ovirtmgmt/
> brif'
> MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
> 14:54:57,726::api::463::root::(_delNetwork) Removing network ovirtmgmt
> with vlan=None, bonding=None, nics=[u'em3'],keep_bridge=False options={}
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,727::ifcfg::335::root::(_atomicNetworkBackup) Backed up ovirtmgmt
> MainProcess|jsonrpc.Executor/6::INFO::2017-05-31
> 14:54:57,729::api::496::root::(_delNetwork) Removing network entity
> ovirtmgmt
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,729::models::188::root::(remove) Removing bridge
> Bridge(ovirtmgmt: Nic(em3))
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,729::utils::671::root::(execCmd) /usr/bin/taskset --cpu-list 0-5
> /usr/sbin/ifdown ovirtmgmt (cwd None)
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,760::utils::689::root::(execCmd) FAILED:  = 'usage: ifdown
> \n';  = 1
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,760::__init__::144::root::(_removeSourceRoute) Removing source
> route for device ovirtmgmt
> MainProcess|jsonrpc.Executor/6::WARNING::2017-05-31
> 14:54:57,761::utils::140::root::(rmFile) File: 
> /etc/sysconfig/network-scripts/rule-ovirtmgmt
> already removed
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,761::ifcfg::292::root::(_removeFile) Removed file
> /etc/sysconfig/network-scripts/rule-ovirtmgmt
> MainProcess|jsonrpc.Executor/6::WARNING::2017-05-31
> 14:54:57,761::utils::140::root::(rmFile) File: 
> /etc/sysconfig/network-scripts/route-ovirtmgmt
> already removed
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,762::ifcfg::292::root::(_removeFile) Removed file
> /etc/sysconfig/network-scripts/route-ovirtmgmt
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,762::utils::671::root::(execCmd) /usr/bin/taskset --cpu-list 0-5
> /usr/sbin/brctl delbr ovirtmgmt (cwd None)
> MainProcess|jsonrpc.Executor/6::DEBUG::2017-05-31
> 14:54:57,769::utils::689::root::(execCmd) FAILED:  = "bridge
> ovirtmgmt doe

Re: [ovirt-devel] [ovirt-users] Lowering the bar for wiki contribution?

[Edward Haas]

On Tue, Jun 20, 2017 at 10:22 PM, Nir Soffer  wrote:

>
> בתאריך יום ג׳, 20 ביוני 2017, 13:10, מאת Martin Sivak ‏ >:
>
>> Hi,
>>
>> I think what Edy did here makes sense. We do not need anything fancy
>> for technical documentation and design. This would also be easy to
>> maintain or integrate to the main website (git submodules will help).
>>
>> I have two basic requirements for design space:
>>
>> - commenting so devs can discuss the design
>> - ease of update so we can respond to comments
>>
>> A plain markdown repo would work well for this and both points are
>> possible using github or gerrit workflows.
>>
>> I would actually prefer if we had something that is directly part of
>> the source repositories so we could review code updates and docs
>> updates together. Unfortunately that it is hard to do when we have
>> multiple different components to update. So this proposal is probably
>> the next best thing.
>>
>
> I think we need a wiki for this, instead of reinventing one :-)
>
> We have a builtin markdown based wiki in the ovirt site github project.
>
> For discussion, we have the mailing list and other channels like bluejeans
> and irc.
>

Discussing reviews through emails?? Good luck with that.
What's next? Sending patches through emails?

I want the power of the review (gerrit/github), not a poor alternative.
The only advantage of github over gerrit in this respect is the already
existing rendering
of the md files.


>
>
> Nir
>
>
>> --
>> Martin Sivak
>> SLA
>>
>>
>> On Thu, Jun 15, 2017 at 8:11 PM, Edward Haas  wrote:
>> > Hi all,
>> >
>> > Came back to this thread due to a need to post some design
>> documentation.
>> > After fetching the ovirt-site and looking up where to start the
>> document, I
>> > remembered why I stopped using it.
>> >
>> > After exploring several options, including the GitHub wiki, I think
>> that for
>> > the development documentation we can just go with the minimum:
>> > Use a repo to just post markdown and image files, letting GitHub
>> > rendering/view of such files to do the job for us.
>> > We can still review the documents and have discussions on the content,
>> and
>> > provide access to all who wants to use it (to perform the merges).
>> > The fact it uses markdown and images, can allow its content to be
>> relocated
>> > to any other solutions that will come later on, including adding the
>> content
>> > back on ovirt-site.
>> >
>> > Here is a simple example:
>> > https://github.com/EdDev/ovirt-devwiki/blob/initial-structure/index.md
>> >
>> > it uses simple markdown md files with relative links to other pages.
>> Adding
>> > images is also simple.
>> >
>> > What do you think?
>> >
>> > Thanks,
>> > Edy.
>> >
>> >
>> >
>> > On Tue, Feb 7, 2017 at 12:42 PM, Michal Skrivanek
>> >  wrote:
>> >>
>> >>
>> >> On 16 Jan 2017, at 11:13, Roy Golan  wrote:
>> >>
>> >>
>> >>
>> >> On 11 January 2017 at 17:06, Marc Dequènes (Duck) 
>> wrote:
>> >>>
>> >>> Quack,
>> >>>
>> >>> On 01/08/2017 06:39 PM, Barak Korren wrote:
>> >>> > On 8 January 2017 at 10:17, Roy Golan  wrote:
>> >>> >> Adding infra which I forgot to add from the beginning
>> >>>
>> >>> Thanks.
>> >>>
>> >>> > I don't think this is an infra issue, more of a community/working
>> >>> > procedures one.
>> >>>
>> >>> I do thin it is. We are involved in the tooling, for their
>> maintenance,
>> >>> for documenting where things are, for suggesting better solutions,
>> >>> ensuring security…
>> >>>
>> >>> > On the one hand, the developers need a place where they create and
>> >>> > discuss design documents and road maps. That please needs to be as
>> >>> > friction-free as possible to allow developers to work on the code
>> >>> > instead of on the documentation tools.
>> >>>
>> >>> As for code, I think there is need for review, even more for design
>> >>> documents, so I don't see why people are bothered by PRs, which is a
>> >>> tool they already know fairly well.
>> >>
>> >>
>

Re: [ovirt-devel] OVN provider's firewalld services deployment during engine setup

[Edward Haas]

My 2 cent on this: Whatever option you choose, do not couple OVN to Engine,
it may cost you less now, but you will find it expensive later.
On the other hand, if the solution is phased into 2 stages, the first just
pushes it in and immediately later does the needed changes to decouple
things, then it may make sense (to the sake of having the feature).

On Tue, Jun 13, 2017 at 10:33 AM, Martin Perina  wrote:

> Will OVN provider be mandatory for all engine 4.2 installation? Can OVN
> provider be installed on different host than engine? If not mandatory or
> "may be on different host", then it should be handled similar way as DWH,
> so it should be in separate package and it's engine-setup part should also
> be in separate package. And even if we don't support OVN on different host
> in 4.2, we can prepare for the future ...
>
> Martin
>
> On Tue, Jun 13, 2017 at 7:36 AM, Yedidyah Bar David 
> wrote:
>
>> On Mon, Jun 12, 2017 at 5:50 PM, Leon Goldberg 
>> wrote:
>> > Hey,
>> >
>> > We're trying to come up with a way to deploy OVN provider's firewalld
>> > services during engine setup. The naive solution of querying the user
>> during
>> > customization and then installing during STAGE_PACKAGES fails as
>> firewalld
>> > configuration happens prior to it.
>> >
>> > We thought of a couple of possible solutions we'd like your opinions on
>> > (ordered in perceived level of difficulty):
>> >
>> > 1) Ship/require the packages with ovirt-engine without requiring user
>> input.
>> > This essentially couples engine with OVN and disregards a future where
>> OVN
>> > doesn't run alongside Engine.
>>
>> How much space will this add? RPMs/Installed-size?
>>
>> This is also what we do today with dwh. It can run in the engine machine
>> or
>> on a different one, but the engine still (indirectly) requires it. So it's
>> always shipped, and if user chooses to not configure it, it still takes
>> space, and user has to set it up elsewhere.
>>
>> >
>> > 2) Install the packages immediately following user input during
>> > customization. A bit hacky and doesn't conceptually fit the stage of
>> > customization.
>> >
>> > 3) Move user input to STAGE_INTERNAL_PACKAGES. Feels more disruptive
>> than #1
>> > to the current otopi flow as STAGE_INTERNAL_PACKAGES is dedicated for
>> > packages that are required for otopi itself to operate. Not only this
>> > doesn't fit conceptually, it introduces user input to a stage that
>> shouldn't
>> > have any.
>> >
>> > 4) Move firewalld configuration to happen after STAGE_PACKAGES.
>>
>> This is a rather big change to how things are done, and breaks iptables
>> support. If we want to keep iptables support, and allow prompting the user
>> with the changes that will be done to iptables [1], we must know
>> beforehand
>> which ports will need to be opened, so we need the firewalld service files
>> during customization.
>>
>> Thinking about this, another option is to package the service files
>> separately (in ovn itself, one day, or in the provider, for now) -
>> and require by the engine only this sub-package, which should be tiny
>> and have no dependencies (except for firewalld perhaps).
>>
>> [1] https://bugzilla.redhat.com/1109326
>>
>> >
>> > 5) Refactor to prepare the grounds for OVN/Engine separation. At this
>> point
>> > this feels very ambiguous. We don't yet know how will containers be
>> accessed
>> > (is ssh guaranteed?) in the future or generally how should a remote
>> > installation look like.
>>
>> Agreed. While "this is the future", I do not think we can do anything
>> worthy
>> for 4.2.
>>
>> Best,
>>
>> >
>> > Any input/questions are appreciated.
>> >
>> > Thanks,
>> > Leon
>>
>>
>>
>> --
>> Didi
>> ___
>> 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

Re: [ovirt-devel] [ovirt-users] Lowering the bar for wiki contribution?

[Edward Haas]

Hi all,

Came back to this thread due to a need to post some design documentation.
After fetching the ovirt-site and looking up where to start the document, I
remembered why I stopped using it.

After exploring several options, including the GitHub wiki, I think that
for the development documentation we can just go with the minimum:
Use a repo to just post markdown and image files, letting GitHub
rendering/view of such files to do the job for us.
We can still review the documents and have discussions on the content, and
provide access to all who wants to use it (to perform the merges).
The fact it uses markdown and images, can allow its content to be relocated
to any other solutions that will come later on, including adding the
content back on ovirt-site.

Here is a simple example:
https://github.com/EdDev/ovirt-devwiki/blob/initial-structure/index.md

it uses simple markdown md files with relative links to other pages. Adding
images is also simple.

What do you think?

Thanks,
Edy.



On Tue, Feb 7, 2017 at 12:42 PM, Michal Skrivanek <
michal.skriva...@redhat.com> wrote:

>
> On 16 Jan 2017, at 11:13, Roy Golan  wrote:
>
>
>
> On 11 January 2017 at 17:06, Marc Dequènes (Duck)  wrote:
>
>> Quack,
>>
>> On 01/08/2017 06:39 PM, Barak Korren wrote:
>> > On 8 January 2017 at 10:17, Roy Golan  wrote:
>> >> Adding infra which I forgot to add from the beginning
>>
>> Thanks.
>>
>> > I don't think this is an infra issue, more of a community/working
>> > procedures one.
>>
>> I do thin it is. We are involved in the tooling, for their maintenance,
>> for documenting where things are, for suggesting better solutions,
>> ensuring security…
>>
>> > On the one hand, the developers need a place where they create and
>> > discuss design documents and road maps. That please needs to be as
>> > friction-free as possible to allow developers to work on the code
>> > instead of on the documentation tools.
>>
>> As for code, I think there is need for review, even more for design
>> documents, so I don't see why people are bothered by PRs, which is a
>> tool they already know fairly well.
>>
>
> because it takes ages to get attention and get it in, even in cases when
> the text/update is more of an FYI and doesn’t require feedback.
> That leads to frustration, and that leads to loss of any motivation to
> contribute anything at all.
> You can see people posting on their own platforms, blogs, just to run away
> from this one
>
>
>> For people with few git knowledge, the GitHub web interface allows to
>> edit files.
>>
>> > On the other hand, the user community needs a good, up to date source
>> > of information about oVirt and how to use it.
>>
>> Yes, this official entry point and it needs to be clean.
>>
>
> yep, you’re right about the entry point -like pages
>
>
>> > Having said the above, I don't think the site project's wiki is the
>> > best place for this. The individual project mirrors on GitHub may be
>> > better for this
>>
>> We could indeed split the technical documentation. If people want to
>> experiment with the GH wiki pages, I won't interfere.
>>
>> I read several people in this thread really miss the old wiki, so I
>> think it is time to remember why we did not stay in paradise. I was not
>> there at the time, but I know the wiki was not well maintained. People
>> are comparing our situation to the MediaWiki site, but the workforce is
>> nowhere to be compared. There is already no community manager, and noone
>> is in charge of any part really, whereas Mediawiki has people in charge
>> of every corner of the wiki. Also they developed tools over years to
>> monitor, correct, revert… and we don't have any of this. So without any
>> process then it was a total mess. More than one year later there was
>> still much cleanup to do, and having contributed to it a little bit, I
>> fear a sentimental rush to go back to a solution that was abandoned.
>>
>
> it was also a bit difficult to edit, plus a barrier of ~1 month it took to
> get an account
>
>
>> Having a header telling if this is a draft or published is far from
>> being sufficient. If noone cares you just pile up content that gets
>> obsolete, then useless, then misleading for newcomers. You may prefer
>> review a posteriori, but in this case you need to have the proper tool
>> to be able to search for things to be reviewed, and a in-content
>> pseudo-header is really not an easy way to get a todolist.
>>
>> As for the current builder, it checks every minute for new content to
>> build. The current tool (Middleman) is a bit slow, and the machine is
>> not ultra speedy, but even in the worst case it should not take more
>> than half an hour to see the published result. So I don't know why
>> someone suggested to build "at least once a day". There is also an
>> experimentation to improve this part.
>>
>> So to sum up:
>>   - the most needed thing here is not a tool but people in charge to
>> review the content (additions, cleanup old things, ask devs to update
>> s

Re: [ovirt-devel] vdsm libs dependencies

[Edward Haas]

On Sun, Jun 11, 2017 at 12:50 PM, Nir Soffer  wrote:

> On Sun, Jun 11, 2017 at 9:35 AM Edward Haas  wrote:
>
>> On Sat, Jun 10, 2017 at 1:27 AM, Dan Kenigsberg 
>> wrote:
>>
>>> On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas  wrote:
>>> >
>>> >
>>> >
>>> >> On 9 Jun 2017, at 19:44, Dan Kenigsberg  wrote:
>>> >>
>>> >>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev 
>>> wrote:
>>> >>> Hello,
>>> >>>
>>> >>>
>>> >>>
>>> >>> I have a question about dependencies of vdsm libraries. Could
>>> somebody
>>> >>> suggest how I can use vdsm.network.ipwrapper from vdsm.storage?
>>> >>>
>>> >>>
>>> >>>
>>> >>> Specifically, I need a way to determine that an IP address of NFS
>>> path is
>>> >>> local. The right way to determine that is as simple as the following:
>>> >>>
>>> >>>
>>> >>>
>>> >>> # /sbin/ip route get X.X.X.X | grep -q ^local && echo IP is local
>>> >>>
>>> >>>
>>> >>>
>>> >>> This is why I need to use vdsm.network.ipwrapper. See details at
>>> >>> https://gerrit.ovirt.org/#/c/68822/
>>> >>
>>> >> I think that we should create a new
>>> >> vdsm.network.api.is_local_address() for this. Do you have a better
>>> >> idea, Edy?
>>> >>
>>> >> P.S I just notice that we have a similar problem in already merged to
>>> iscsi.py:
>>> >>
>>> >> from vdsm.network.netinfo.routes import getRouteDeviceTo
>>> >>
>>> >> should be similarly avoided.
>>> >
>>> > Anyone outside the network subtree accessing anything except the api
>>> module is in risk, as internals may be changed or removed. It is equivalent
>>> to accessing a private attribute in python.
>>> >
>>> > In general I am not in favor of contacting the network package for
>>> things that are not really its main business logic. Asking it if an IP is
>>> under one of the networks it manages seems fine, but asking this in general
>>> for the host is something else.
>>> > This could fit a helper in common.network, but we'll need execCmd
>>> moved to common first.
>>>
>>> I'd like to assist Paval ASAP, and removing the storage dep on network
>>> internal is also urgent for the task of network separation. Do we have
>>> a short timeline for moving execCmd? If not, would you consider ad-hoc
>>> api entries?
>>>
>>
>> It's actually not urgent for network separation, storage is dependent on
>> network anyway and it is part of it's strategy on how to separate itself.
>>
>
> I don't know about any dependency on network in storage, except the
> iscsi rp filter, which should be fixed by moving this functionality to
> common.
>
>
>> I have no plans for execCmd, it required too much changes for moving it
>> to common
>>
>
> execCmd will move to common soon, together will all the code under
> lib/vdsm/
>
> We will not create another copy of execCmd, in common, we need to remove
> the unneeded copy under network instead.
>

I do not see this happening any-time soon unless you know anyone who took
this task on himself.
Network has now a very simple version as it does not need any special
functionality.


>
>
>> and we found a workaround (network.cmd).
>> We could implement a simple local exec command using C/Popen under
>> common.network if you are ok with it. And we will need to implement part of
>> the parsing (or use grep as suggested).
>>
>
> Why not move the ipwrapper module to common? This module should
> not have anything which with network business logic, just an easy way
> to run this command - just like udevadm, this does not belong to any
> subsystem.
>

Because ipwrapper does 100 things and you now just need 1 of those.
We should move to common only heavy used functionality with enough
complexity to be worth it.
Contaminating common with too much noise is also bad, we need some balance.


>
>> I do not think we should expose "ip route.." commands as vdsm-network api
>> (network.api), it feels wrong.
>>
>
> Pavel needs a way to detect if an ip address (ipv4/6) is the address of
> the local host, so we can use bind mount instead of regular mount.
> See https://gerrit.ovirt.org/68822
>
> I don't see a need to depend on network package for this, this is not
> a service of the network package.
>
> If you think these should be a service of the network package, we
> need an entry point to access these apis.
>



>
> Nir
>
>
>>
>>
>> ___
>> 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

Re: [ovirt-devel] vdsm libs dependencies

[Edward Haas]

> On 9 Jun 2017, at 19:44, Dan Kenigsberg  wrote:
> 
>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev  wrote:
>> Hello,
>> 
>> 
>> 
>> I have a question about dependencies of vdsm libraries. Could somebody
>> suggest how I can use vdsm.network.ipwrapper from vdsm.storage?
>> 
>> 
>> 
>> Specifically, I need a way to determine that an IP address of NFS path is
>> local. The right way to determine that is as simple as the following:
>> 
>> 
>> 
>> # /sbin/ip route get X.X.X.X | grep -q ^local && echo IP is local
>> 
>> 
>> 
>> This is why I need to use vdsm.network.ipwrapper. See details at
>> https://gerrit.ovirt.org/#/c/68822/
> 
> I think that we should create a new
> vdsm.network.api.is_local_address() for this. Do you have a better
> idea, Edy?
> 
> P.S I just notice that we have a similar problem in already merged to 
> iscsi.py:
> 
> from vdsm.network.netinfo.routes import getRouteDeviceTo
> 
> should be similarly avoided.

Anyone outside the network subtree accessing anything except the api module is 
in risk, as internals may be changed or removed. It is equivalent to accessing 
a private attribute in python. 

In general I am not in favor of contacting the network package for things that 
are not really its main business logic. Asking it if an IP is under one of the 
networks it manages seems fine, but asking this in general for the host is 
something else.
This could fit a helper in common.network, but we'll need execCmd moved to 
common first.

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

Re: [ovirt-devel] vdsm libs dependencies

[Edward Haas]

On Sat, Jun 10, 2017 at 1:27 AM, Dan Kenigsberg  wrote:

> On Fri, Jun 9, 2017 at 10:09 PM, Edward Haas  wrote:
> >
> >
> >
> >> On 9 Jun 2017, at 19:44, Dan Kenigsberg  wrote:
> >>
> >>> On Fri, Jun 9, 2017 at 2:49 PM, Pavel Gashev  wrote:
> >>> Hello,
> >>>
> >>>
> >>>
> >>> I have a question about dependencies of vdsm libraries. Could somebody
> >>> suggest how I can use vdsm.network.ipwrapper from vdsm.storage?
> >>>
> >>>
> >>>
> >>> Specifically, I need a way to determine that an IP address of NFS path
> is
> >>> local. The right way to determine that is as simple as the following:
> >>>
> >>>
> >>>
> >>> # /sbin/ip route get X.X.X.X | grep -q ^local && echo IP is local
> >>>
> >>>
> >>>
> >>> This is why I need to use vdsm.network.ipwrapper. See details at
> >>> https://gerrit.ovirt.org/#/c/68822/
> >>
> >> I think that we should create a new
> >> vdsm.network.api.is_local_address() for this. Do you have a better
> >> idea, Edy?
> >>
> >> P.S I just notice that we have a similar problem in already merged to
> iscsi.py:
> >>
> >> from vdsm.network.netinfo.routes import getRouteDeviceTo
> >>
> >> should be similarly avoided.
> >
> > Anyone outside the network subtree accessing anything except the api
> module is in risk, as internals may be changed or removed. It is equivalent
> to accessing a private attribute in python.
> >
> > In general I am not in favor of contacting the network package for
> things that are not really its main business logic. Asking it if an IP is
> under one of the networks it manages seems fine, but asking this in general
> for the host is something else.
> > This could fit a helper in common.network, but we'll need execCmd moved
> to common first.
>
> I'd like to assist Paval ASAP, and removing the storage dep on network
> internal is also urgent for the task of network separation. Do we have
> a short timeline for moving execCmd? If not, would you consider ad-hoc
> api entries?
>

It's actually not urgent for network separation, storage is dependent on
network anyway and it is part of it's strategy on how to separate itself.
I have no plans for execCmd, it required too much changes for moving it to
common and we found a workaround (network.cmd).
We could implement a simple local exec command using C/Popen under
common.network if you are ok with it. And we will need to implement part of
the parsing (or use grep as suggested).
I do not think we should expose "ip route.." commands as vdsm-network api
(network.api), it feels wrong.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ovirt_master_hc-system-tests failed

[Edward Haas]

Hello,

This patch has been merged recently: https://gerrit.ovirt.org/#/c/76855/
New appliances should not have openvswitch missing.

Thanks,
Edy.

On Tue, May 23, 2017 at 10:05 AM, Gil Shinar  wrote:

> Hi Sahina,
>
> Thanks a lot for looking into it.
> Adding ovirt devel.
>
> On Tue, May 23, 2017 at 9:51 AM, Sahina Bose  wrote:
>
>> From the logs, it looks like an issue installing the HE
>>
>>  [ INFO  ] Stopping websocket-proxy service", "  |- [ INFO  ]
>> Stage: Misc configuration", "  |- [ INFO  ] Stage: Package
>> installation", "  |- [ INFO  ] Stage: Misc configuration",
>> "  |- [ ERROR ] Failed to execute stage 'Misc configuration':
>> Failed to enable service 'openvswitch'", "  |- [ INFO  ] Stage:
>> Clean up", "  |-   Log file is located at
>> /var/log/ovirt-engine/setup/ovirt-engine-setup-20170522230910-t50bkj.log",
>> "  |- [ INFO  ] Generating answer file
>> '/var/lib/ovirt-engine/setup/answers/20170522230919-setup.conf'",
>> "  |- [ INFO  ] Stage: Pre-termination", "  |- [ INFO  ]
>> Stage: Termination", "  |- [ ERROR ] Execution of setup failed",
>> "  |- HE_APPLIANCE_ENGINE_SETUP_FAIL", "[ ERROR ] Engine setup
>> failed on the appliance", "[ ERROR ] Failed to execute stage 'Closing up':
>> Engine setup failed on the appliance", "
>>
>> And from the /var/log/ovirt-engine/setup/ovirt-engine-setup-2017052223091
>> 0-t50bkj.log:
>> 2017-05-22 23:09:19,645-0400 DEBUG otopi.plugins.otopi.services.systemd
>> plugin.execute:926 execute-output: ('/bin/systemctl', 'enable',
>> u'openvswitch.service') stderr:
>> Failed to execute operation: No such file or directory
>>
>> 2017-05-22 23:09:19,645-0400 DEBUG otopi.context
>> context._executeMethod:142 method exception
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in
>> _executeMethod
>> method['method']()
>>   File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-
>> setup/ovirt-engine/network/ovirtproviderovn.py", line 531, in
>> _restart_ovn_services
>> self._restart_service(service)
>>   File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-
>> setup/ovirt-engine/network/ovirtproviderovn.py", line 513, in
>> _restart_service
>> state=True,
>>   File "/usr/share/otopi/plugins/otopi/services/systemd.py", line 122,
>> in startup
>> service=name,
>> RuntimeError: Failed to enable service 'openvswitch'
>>
>>
>>
>> On Sun, May 21, 2017 at 1:32 PM, Gil Shinar  wrote:
>>
>>> Hi Sahina,
>>>
>>> Can you please assist?
>>> http://jenkins.ovirt.org/job/ovirt_master_hc-system-tests/105/
>>>
>>> Thanks
>>> Gil
>>>
>>
>>
>
> ___
> 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

Re: [ovirt-devel] [VDSM] network test failure - failing all builds

[Edward Haas]

Tried to handle this using: https://gerrit.ovirt.org/#/c/76781

Thanks,
Edy.

On Sat, May 13, 2017 at 1:02 AM, Edward Haas  wrote:

> It may have been a patch (not particular one that got merged) that messed
> up the ci hosts.
> Looks better now, recent checks passed.
>
> Will try to monitor it later on.
>
> Thanks,
> Edy.
>
> On Sat, May 13, 2017 at 12:45 AM, Edward Haas  wrote:
>
>> Very strange (and very late), trying to simulate locally.
>>
>> On Sat, May 13, 2017 at 12:22 AM, Nir Soffer  wrote:
>>
>>> Test trends:
>>> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc25-x8
>>> 6_64/buildTimeTrend
>>> http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86
>>> _64/buildTimeTrend
>>> <http://jenkins.ovirt.org/view/01%20Unstable%20Jobs%20(ALL)/job/vdsm_master_check-patch-el7-x86_64/buildTimeTrend>
>>>
>>> On Sat, May 13, 2017 at 12:16 AM Nir Soffer  wrote:
>>>
>>>> I'm seeing now this failure on multiple untreated patches.
>>>>
>>>> Seems to be related to these patches merged today:
>>>> https://gerrit.ovirt.org/#/q/topic:ip_refactoring+is:merged
>>>>
>>>> *21:04:36* 
>>>> ==*21:04:36*
>>>>  FAIL: test_add_delete_and_read_rule 
>>>> (network.ip_rule_test.TestIpRule)*21:04:36* 
>>>> --*21:04:36*
>>>>  Traceback (most recent call last):*21:04:36*   File 
>>>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/network/ip_rule_test.py",
>>>>  line 47, in test_add_delete_and_read_rule*21:04:36* 
>>>> self.assertEqual(1, len(rules))*21:04:36* AssertionError: 1 != 2*21:04:36* 
>>>>  >> begin captured logging << 
>>>> *21:04:36* 2017-05-12 21:04:18,381 DEBUG (MainThread) 
>>>> [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip rule add from all to 
>>>> 192.168.99.1 dev lo table main (cwd None) (commands:69)*21:04:36* 
>>>> 2017-05-12 21:04:18,393 DEBUG (MainThread) [root] SUCCESS:  = ''; 
>>>>  = 0 (commands:93)*21:04:36* 2017-05-12 21:04:18,393 DEBUG 
>>>> (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip rule (cwd 
>>>> None) (commands:69)*21:04:36* 2017-05-12 21:04:18,404 DEBUG (MainThread) 
>>>> [root] SUCCESS:  = '';  = 0 (commands:93)*21:04:36* 2017-05-12 
>>>> 21:04:18,406 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 
>>>> /sbin/ip rule del from all to 192.168.99.1 dev lo table main (cwd None) 
>>>> (commands:69)*21:04:36* 2017-05-12 21:04:18,417 DEBUG (MainThread) [root] 
>>>> SUCCESS:  = '';  = 0 (commands:93)*21:04:36* 
>>>> - >> end captured logging << -
>>>>
>>>>
>>>>
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] network test failure - failing all builds

[Edward Haas]

It may have been a patch (not particular one that got merged) that messed
up the ci hosts.
Looks better now, recent checks passed.

Will try to monitor it later on.

Thanks,
Edy.

On Sat, May 13, 2017 at 12:45 AM, Edward Haas  wrote:

> Very strange (and very late), trying to simulate locally.
>
> On Sat, May 13, 2017 at 12:22 AM, Nir Soffer  wrote:
>
>> Test trends:
>> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc25-x8
>> 6_64/buildTimeTrend
>> http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86
>> _64/buildTimeTrend
>> <http://jenkins.ovirt.org/view/01%20Unstable%20Jobs%20(ALL)/job/vdsm_master_check-patch-el7-x86_64/buildTimeTrend>
>>
>> On Sat, May 13, 2017 at 12:16 AM Nir Soffer  wrote:
>>
>>> I'm seeing now this failure on multiple untreated patches.
>>>
>>> Seems to be related to these patches merged today:
>>> https://gerrit.ovirt.org/#/q/topic:ip_refactoring+is:merged
>>>
>>> *21:04:36* 
>>> ==*21:04:36*
>>>  FAIL: test_add_delete_and_read_rule 
>>> (network.ip_rule_test.TestIpRule)*21:04:36* 
>>> --*21:04:36*
>>>  Traceback (most recent call last):*21:04:36*   File 
>>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/network/ip_rule_test.py",
>>>  line 47, in test_add_delete_and_read_rule*21:04:36* 
>>> self.assertEqual(1, len(rules))*21:04:36* AssertionError: 1 != 2*21:04:36* 
>>>  >> begin captured logging << 
>>> *21:04:36* 2017-05-12 21:04:18,381 DEBUG (MainThread) 
>>> [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip rule add from all to 
>>> 192.168.99.1 dev lo table main (cwd None) (commands:69)*21:04:36* 
>>> 2017-05-12 21:04:18,393 DEBUG (MainThread) [root] SUCCESS:  = '';  
>>> = 0 (commands:93)*21:04:36* 2017-05-12 21:04:18,393 DEBUG (MainThread) 
>>> [root] /usr/bin/taskset --cpu-list 0-1 /sbin/ip rule (cwd None) 
>>> (commands:69)*21:04:36* 2017-05-12 21:04:18,404 DEBUG (MainThread) [root] 
>>> SUCCESS:  = '';  = 0 (commands:93)*21:04:36* 2017-05-12 
>>> 21:04:18,406 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 
>>> /sbin/ip rule del from all to 192.168.99.1 dev lo table main (cwd None) 
>>> (commands:69)*21:04:36* 2017-05-12 21:04:18,417 DEBUG (MainThread) [root] 
>>> SUCCESS:  = '';  = 0 (commands:93)*21:04:36* - 
>>> >> end captured logging << -
>>>
>>>
>>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] network test failure - failing all builds

[Edward Haas]

Very strange (and very late), trying to simulate locally.

On Sat, May 13, 2017 at 12:22 AM, Nir Soffer  wrote:

> Test trends:
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc25-
> x86_64/buildTimeTrend
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-
> x86_64/buildTimeTrend
> 
>
> On Sat, May 13, 2017 at 12:16 AM Nir Soffer  wrote:
>
>> I'm seeing now this failure on multiple untreated patches.
>>
>> Seems to be related to these patches merged today:
>> https://gerrit.ovirt.org/#/q/topic:ip_refactoring+is:merged
>>
>> *21:04:36* 
>> ==*21:04:36*
>>  FAIL: test_add_delete_and_read_rule 
>> (network.ip_rule_test.TestIpRule)*21:04:36* 
>> --*21:04:36*
>>  Traceback (most recent call last):*21:04:36*   File 
>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/network/ip_rule_test.py",
>>  line 47, in test_add_delete_and_read_rule*21:04:36* self.assertEqual(1, 
>> len(rules))*21:04:36* AssertionError: 1 != 2*21:04:36*  
>> >> begin captured logging << *21:04:36* 2017-05-12 
>> 21:04:18,381 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 
>> /sbin/ip rule add from all to 192.168.99.1 dev lo table main (cwd None) 
>> (commands:69)*21:04:36* 2017-05-12 21:04:18,393 DEBUG (MainThread) [root] 
>> SUCCESS:  = '';  = 0 (commands:93)*21:04:36* 2017-05-12 
>> 21:04:18,393 DEBUG (MainThread) [root] /usr/bin/taskset --cpu-list 0-1 
>> /sbin/ip rule (cwd None) (commands:69)*21:04:36* 2017-05-12 21:04:18,404 
>> DEBUG (MainThread) [root] SUCCESS:  = '';  = 0 
>> (commands:93)*21:04:36* 2017-05-12 21:04:18,406 DEBUG (MainThread) [root] 
>> /usr/bin/taskset --cpu-list 0-1 /sbin/ip rule del from all to 192.168.99.1 
>> dev lo table main (cwd None) (commands:69)*21:04:36* 2017-05-12 21:04:18,417 
>> DEBUG (MainThread) [root] SUCCESS:  = '';  = 0 
>> (commands:93)*21:04:36* - >> end captured logging << 
>> -
>>
>>
>>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Vdsm merge rights

[Edward Haas]

Good news! +2

On Fri, May 12, 2017 at 11:27 AM, Piotr Kliczewski 
wrote:

> +1
>
> On Fri, May 12, 2017 at 9:14 AM, Dan Kenigsberg  wrote:
>
>> I'd like to nominate Francesco to the vdsm-maintainers
>> https://gerrit.ovirt.org/#/admin/groups/uuid-becbf722723417c
>> 336de6c1646749678acae8b89
>> list, so he can merge patches without waiting for Nir, Adam or me.
>>
>> I believe that he proved to be thorough and considerate (and paranoid)
>> as the job requires.
>>
>> Vdsm maintainers, please approve.
>>
>> Dan
>>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master][09-05-2017][ 002_bootstrap.add_hosts ]

[Edward Haas]

This patch should fix it: https://gerrit.ovirt.org/#/c/76630
Checked against OST and it passed.

Some small debate on the how in the patch, will check with Dan to merge an
agreed version asap.

On Tue, May 9, 2017 at 3:53 PM, Oved Ourfali  wrote:

> CC-ing Edi.
>
>
> On Tue, May 9, 2017 at 3:46 PM, Yedidyah Bar David 
> wrote:
>
>> On Tue, May 9, 2017 at 3:44 PM, Piotr Kliczewski
>>  wrote:
>> > It seems to be broken by this patch [1]
>> >
>> >
>> > [1] https://gerrit.ovirt.org/#/c/76603
>>
>> Indeed. Please revert for now [1], then investigate.
>>
>> [1] https://gerrit.ovirt.org/76626
>>
>> >
>> > On Tue, May 9, 2017 at 2:40 PM, Anton Marchukov 
>> wrote:
>> >> Hello.
>> >>
>> >> Today around 11 am the add host for master started to consistently
>> fail.
>> >>
>> >> We found the following in /var/log/messages (as I understand it might
>> get
>> >> there through journald as the host deploy log claims that vdsmd unit
>> startup
>> >> failed):
>> >>
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: Traceback
>> (most
>> >> recent call last):
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
>> >> "/usr/bin/vdsm-tool", line 219, in main
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: return
>> >> tool_command[cmd]["command"](*args)
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
>> >> "/usr/lib/python2.7/site-packages/vdsm/tool/network.py", line 48, in
>> >> upgrade_networks
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
>> >> netupgrade.upgrade()
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
>> >> "/usr/lib/python2.7/site-packages/vdsm/network/netupgrade.py", line
>> 55, in
>> >> upgrade
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
>> >> _create_unified_configuration(rconfig, NetInfo(netinfo(vdsmnets)))
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
>> >> "/usr/lib/python2.7/site-packages/vdsm/network/netupgrade.py", line
>> 133, in
>> >> _create_unified_configuration
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
>> >> RunningConfig.store()
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
>> >> "/usr/lib/python2.7/site-packages/vdsm/network/netconfpersistence.py",
>> line
>> >> 204, in store
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
>> _store_net_config()
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
>> >> "/usr/lib/python2.7/site-packages/vdsm/network/netconfpersistence.py",
>> line
>> >> 281, in _store_net_config
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
>> >> utils.rmTree(real_old_safeconf_dir)
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
>> >> "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 125, in rmTree
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
>> >> shutil.rmtree(directoryToRemove)
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
>> >> "/usr/lib64/python2.7/shutil.py", line 232, in rmtree
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
>> >> onerror(os.path.islink, path, sys.exc_info())
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
>> >> "/usr/lib64/python2.7/shutil.py", line 230, in rmtree
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: raise
>> >> OSError("Cannot call rmtree on a symbolic link")
>> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: OSError:
>> Cannot
>> >> call rmtree on a symbolic link
>> >> May  9 07:01:25 lago-basic-suite-master-host1 systemd:
>> vdsm-network.service:
>> >> control process exited, code=exited status=1
>> >>
>> >>
>> >> The full logs of the run you can find in Jenkins artifacts:
>> >>
>> >> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_ma
>> ster/6589/artifact/exported-artifacts/basic-suit-master-el7/
>> test_logs/basic-suite-master/post-002_bootstrap.py/
>> >>
>> >>
>> >> Any vdsm patches merged that might cause this?
>> >>
>> >> --
>> >>
>> >> Anton Marchukov
>> >> Senior Software Engineer - RHEV CI - Red Hat
>> >>
>> >>
>> >> ___
>> >> 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
>>
>>
>>
>> --
>> Didi
>> ___
>> 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

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master][09-05-2017][ 002_bootstrap.add_hosts ]

[Edward Haas]

You cannot revert it, the original was wrong.
This is not suppose to be a symlink but an actual directory.
QE reported it to fail yesterday.


On Tue, May 9, 2017 at 3:46 PM, Yedidyah Bar David  wrote:

> On Tue, May 9, 2017 at 3:44 PM, Piotr Kliczewski
>  wrote:
> > It seems to be broken by this patch [1]
> >
> >
> > [1] https://gerrit.ovirt.org/#/c/76603
>
> Indeed. Please revert for now [1], then investigate.
>
> [1] https://gerrit.ovirt.org/76626
>
> >
> > On Tue, May 9, 2017 at 2:40 PM, Anton Marchukov 
> wrote:
> >> Hello.
> >>
> >> Today around 11 am the add host for master started to consistently fail.
> >>
> >> We found the following in /var/log/messages (as I understand it might
> get
> >> there through journald as the host deploy log claims that vdsmd unit
> startup
> >> failed):
> >>
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: Traceback (most
> >> recent call last):
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/bin/vdsm-tool", line 219, in main
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: return
> >> tool_command[cmd]["command"](*args)
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib/python2.7/site-packages/vdsm/tool/network.py", line 48, in
> >> upgrade_networks
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
> >> netupgrade.upgrade()
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib/python2.7/site-packages/vdsm/network/netupgrade.py", line
> 55, in
> >> upgrade
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
> >> _create_unified_configuration(rconfig, NetInfo(netinfo(vdsmnets)))
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib/python2.7/site-packages/vdsm/network/netupgrade.py", line
> 133, in
> >> _create_unified_configuration
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
> >> RunningConfig.store()
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib/python2.7/site-packages/vdsm/network/netconfpersistence.py",
> line
> >> 204, in store
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
> _store_net_config()
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib/python2.7/site-packages/vdsm/network/netconfpersistence.py",
> line
> >> 281, in _store_net_config
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
> >> utils.rmTree(real_old_safeconf_dir)
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 125, in rmTree
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
> >> shutil.rmtree(directoryToRemove)
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib64/python2.7/shutil.py", line 232, in rmtree
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool:
> >> onerror(os.path.islink, path, sys.exc_info())
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: File
> >> "/usr/lib64/python2.7/shutil.py", line 230, in rmtree
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: raise
> >> OSError("Cannot call rmtree on a symbolic link")
> >> May  9 07:01:25 lago-basic-suite-master-host1 vdsm-tool: OSError: Cannot
> >> call rmtree on a symbolic link
> >> May  9 07:01:25 lago-basic-suite-master-host1 systemd:
> vdsm-network.service:
> >> control process exited, code=exited status=1
> >>
> >>
> >> The full logs of the run you can find in Jenkins artifacts:
> >>
> >> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_
> master/6589/artifact/exported-artifacts/basic-suit-master-
> el7/test_logs/basic-suite-master/post-002_bootstrap.py/
> >>
> >>
> >> Any vdsm patches merged that might cause this?
> >>
> >> --
> >>
> >> Anton Marchukov
> >> Senior Software Engineer - RHEV CI - Red Hat
> >>
> >>
> >> ___
> >> 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
>
>
>
> --
> Didi
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Firewalld migration.

[Edward Haas]

> On 27 Mar 2017, at 17:05, Leon Goldberg  wrote:
> 
> > Why do we need to use firewalld?
> I think that the initial trigger was the realization we're completely lacking 
> ipv6 handling (which requires use of another, similar tool in ip6tables) in 
> the current infrastructure. 
> 
> Assessing the situation and reviewing the code for potential solutions led us 
> to a couple of conclusions:
> 
> - Current flow is overly complex and should be reexamined regardless.
> - The naive solution would be to duplicate the current flow for ip6tables, 
> potentially leading to a lot of boilerplate code. I'm sure there are more 
> sophisticated solutions that could be implemented within the current 
> infrastructure, but firewalld naturally came up as it allows us to handle 
> both ipv4 and ipv6 via a single entity.
> - As many of the services are already statically provided by either firewalld 
> or 3rd party packages, we'll be able to merely pass names of services instead 
> of complete rule sets.
> - el7 is shipped with and makes use of firewalld by default.
> 
> > What is the role of the central management in this regard?
> I'd like its role to be as insignificant as possible.
> 
> > -- Does it need to manage firewalls per host in detail? (are we acting as a 
> > firewall management system?)
> No. Ansible was recently brought up as a solution/replacement to custom  
> rules/service deployment, and other than that, there is no justification to 
> having central management. The hosts have the required information to 
> determine which services/rules should be enabled on them (via either vdsm or 
> otopi)
> 
> > -- Does it need to apply a firewall template configuration to all the 
> > hosts? (all being identical)
> > -- Does it need to specify what services it wants the host to run and 
> > mention if the whole setup should be harden or not?
> If we do decide to keep Engine's involvement, it should be as minimal as 
> possible. Names of required services should be provided and that's it, in my 
> opinion (and even that sounds wasteful).
> 
> > As far as I know, firewalld and iptables can co-exist, therefore, I do not 
> > see the need to 'upgrade' or perform a hard replacement.
> > It can be done as an option (firewall-type: iptables/firewalld).
> > On upgrade it continues with the 'old' definition and on new created host 
> > the default can be firewalld.
> > Is someone will explicitly want to change it from one to the other, we 
> > could go with remove/add approach to make things simpler.
> firewalld doesn't play well with iptables' service. Enabling firewalld 
> disables iptables' service and flushes its rules. 

Understood, good to know.
But still, this approach will work fine, we do the same with linux/ovs bridge 
options. Add an option to choose the  firewall type. Support both at phase 1, 
allowing to change the type and at phase 2 deprecate the iptables type.

> 
> > I personally like the distributed approach, where the upper management 
> > layer passes what it wants to the lower layers with minimum information. 
> > Letting the lower levels
> > do the explicit work and figure out what they need to do.
> > If that was the original approach, Engine would have not 'care' what type 
> > of firewall you use down at the host, you could even use a custom firewall, 
> > an NFV firewall solution
> > or anything that may pop up in the future.
> > Engine would have just said: I want libvirt, vdsm, ssh, etc... services 
> > opened (for access from ...).
> > Custom settings? That implies we manage firewalls. So either let the user 
> > add their special stuff on the hosts or provide them with a proper firewall 
> > management interface.
> Agreed. I'll go even further and write that Engine shouldn't even state the 
> services hosts require; a host should be self aware of the services it needs 
> to use based on the relevant configuration (e.g. if gluster is supported in 
> the cluster, enable gluster service)
> 
>> On Sun, Mar 26, 2017 at 4:47 PM, Edward Haas  wrote:
>> 
>> I may be too naive, but it all sounds too complex to me.
>> Is there any reference to the use cases of the firewall configuration?
>> 
>> Few questions:
>> - Why do we need to use firewalld?
>> - What is the role of the central management in this regard?
>> -- Does it need to manage firewalls per host in detail? (are we acting as a 
>> firewall management system?)
>> -- Does it need to apply a firewall template configuration to all the hosts? 
>> (all being identical)
>> -- Does it need to specify what

Re: [ovirt-devel] Firewalld migration.

[Edward Haas]

On Mon, Mar 27, 2017 at 7:07 PM, Martin Sivak  wrote:

> > Clients should be made aware their custom rules are going to be obsolete
> and
> > that they should reapply them once they reinstall.
>
> Would you want to manually fix every reinstalled host? I would
> consider that very annoying. This has to be somewhat automatic if we
> want to support custom firewall rules. And although I agree the engine
> is not the right place for that, it is the only central place we have
> and from which we are starting the reinstall task.
>

But we do not want to support custom firewall rules, we are not a firewall
manager.
IMO, oVirt should support the hardening of its services and co-exist with
other rules.
Custom firewall settings imply one of these:
- We need to extend current firewall options.
- It needs to be implemented outside oVirt.

But if the need to support back doors is proven to be a must, then
implement them
outside the main core solution, these edge cases should not block the main
business
logic.



>
> Martin
>
> On Mon, Mar 27, 2017 at 4:16 PM, Leon Goldberg 
> wrote:
> > You're right, but I don't think it matters; hosts will remain unaffected
> > until they're reinstalled via an upgraded Engine.
> >
> > Clients should be made aware their custom rules are going to be obsolete
> and
> > that they should reapply them once they reinstall.
> >
> > On Mon, Mar 27, 2017 at 9:01 AM, Yedidyah Bar David 
> wrote:
> >>
> >> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg 
> >> wrote:
> >> > Effectively, upgrading will leave lingering (but nonetheless
> >> > operational)
> >> > iptables rules on the hosts. I'm not even sure there needs to be
> special
> >> > upgrade treatment?
> >>
> >> Please describe the expected flow.
> >>
> >> Please note that at least when I tried, 'systemctl start firewalld'
> stops
> >> iptables.
> >>
> >> Thanks,
> >>
> >> >
> >> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David 
> >> > wrote:
> >> >>
> >> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg 
> >> >> wrote:
> >> >> > 1) Do we actually need iptables for any reason that isn't a legacy
> >> >> > consideration?
> >> >>
> >> >> No idea personally.
> >> >>
> >> >> Perhaps some users prefer that, and/or need that for integration with
> >> >> other
> >> >> systems/solutions/whatever.
> >> >>
> >> >> If we drop iptables, how do you suggest to treat upgrades?
> >> >>
> >> >> >
> >> >> > 2 & 3) I am in favor of treating custom services as a requirement
> and
> >> >> > plan
> >> >> > accordingly. Many (most, even) of the services are already provided
> >> >> > by
> >> >> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party
> >> >> > packages
> >> >> > (e.g.
> >> >> > gluster). Some are missing (I've recently created a pull request
> for
> >> >> > ovirt-imageio to firewalld, for example) and I hope we'll be able
> to
> >> >> > get
> >> >> > all
> >> >> > the services to be statically provided (by either firewalld or the
> >> >> > relevant
> >> >> > 3rd party packages).
> >> >> >
> >> >> > Ideally I think we'd like use statically provided services, and
> >> >> > provide
> >> >> > the
> >> >> > capability to provide additional services (I'm not a fan of the
> >> >> > current
> >> >> > methodology of converting strings into xmls). I don't think we'd
> want
> >> >> > to
> >> >> > limit usage to just statically provided services. (2)
> >> >> >
> >> >> > As previously stated, I don't see a technical reason to keep
> iptables
> >> >> > under
> >> >> > consideration. (3)
> >> >> >
> >> >> >
> >> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <
> d...@redhat.com>
> >> >> > wrote:
> >> >> >>
> >> >> >>
> >> >> >> 1. Do we want to support in some version X both iptables and
> >> >> >> firewalld,
> >> >> >> or
> >> >> >> is it ok to stop support for iptables and support only firewalld
> >> >> >> without
> >> >> >> overlap? If so, do we handle upgrades, and how?
> >> >> >>
> >> >> >> 2. Do we want to support custom firewalld xml to be configured on
> >> >> >> the
> >> >> >> host by us? Or is it ok to only support choosing among existing
> >> >> >> services,
> >> >> >> which will need to be added to the host using other means
> (packaged
> >> >> >> by
> >> >> >> firewalld, packaged by 3rd parties, added manually by users)?
> >> >> >>
> >> >> >> 3. Opposite of (2.): Do we want to support firewalld services that
> >> >> >> are
> >> >> >> added to the host using other means (see there)? Obviously we do,
> >> >> >> but:
> >> >> >> If we do, do we still want to support also iptables (see (1.))?
> And
> >> >> >> if
> >> >> >> so, what do we want to then happen?
> >> >> >>
> >> >> >> (2.) and (3.) are not conflicting, each needs its own answer.
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Didi
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Didi
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Didi
> >
> >
> >
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.

Re: [ovirt-devel] vdsm-hook-ovs dependency

[Edward Haas]

Hi Daniel,

vdsm-hook-ovs has been removed on both master and 4.1, see
https://gerrit.ovirt.org/#/c/69849/

Thanks,
Edy.

On Sun, Mar 26, 2017 at 3:30 PM, Daniel Belenky  wrote:

> Hi all,
>
> I try to test our master tested repo for repoclosure, and the test fails on 
> the following dependency:
>
> 10:44:49 package: vdsm-hook-ovs-4.20.0-162.gitcc43be6.el7.centos.noarch from 
> internal_repo
> 10:44:49   unresolved deps:
> 10:44:49  vdsm = 0:4.20.0-162.gitcc43be6.el7.centos
>
> When looking at the last builds of VDSM, I could not find this package: 
> *vdsm-hook-ovs* in the 'exported artifacts'.
> Can someone advise where this package is coming from? Do we need this package?
>
> Thanks,
>
> --
>
> *Daniel Belenky*
>
> *RHV DevOps*
>
> *Red Hat Israel*
>
> ___
> 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

Re: [ovirt-devel] Firewalld migration.

[Edward Haas]

I may be too naive, but it all sounds too complex to me.
Is there any reference to the use cases of the firewall configuration?

Few questions:
- Why do we need to use firewalld?
- What is the role of the central management in this regard?
-- Does it need to manage firewalls per host in detail? (are we acting as a
firewall management system?)
-- Does it need to apply a firewall template configuration to all the
hosts? (all being identical)
-- Does it need to specify what services it wants the host to run and
mention if the whole setup should be harden or not?

As far as I know, firewalld and iptables can co-exist, therefore, I do not
see the need to 'upgrade' or perform a hard replacement.
It can be done as an option (firewall-type: iptables/firewalld).
On upgrade it continues with the 'old' definition and on new created host
the default can be firewalld.
Is someone will explicitly want to change it from one to the other, we
could go with remove/add approach to make things simpler.

I personally like the distributed approach, where the upper management
layer passes what it wants to the lower layers with minimum information.
Letting the lower levels
do the explicit work and figure out what they need to do.
If that was the original approach, Engine would have not 'care' what type
of firewall you use down at the host, you could even use a custom firewall,
an NFV firewall solution
or anything that may pop up in the future.
Engine would have just said: I want libvirt, vdsm, ssh, etc... services
opened (for access from ...).
Custom settings? That implies we manage firewalls. So either let the user
add their special stuff on the hosts or provide them with a proper firewall
management interface.

Thanks,
Edy.


On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David  wrote:

> On Sun, Mar 26, 2017 at 2:12 PM, Oved Ourfali  wrote:
> >
> >
> > On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg 
> wrote:
> >>
> >> Hey Oved,
> >>
> >> I don't think completely moving away from iptables is foreseeable at
> this
> >> point, but I could be of course wrong. Either way, upgrading still
> needs to
> >> be thought of.
> >>
> >
> > I see.
> >
> >>
> >> By stating that the current infrastructure is complex, I was referring
> to
> >> the entire chain of storing rules in the database, fetching them using a
> >> dedicated deployment class consisting of include/exclude logic, sending
> them
> >> over, unpacking, deploying...
> >>
> >> This procedure involves a lot of code that could be made redundant if
> the
> >> required logic is present in the host, which to me seems favorable. It
> of
> >> course entails other potential difficulties, primarily in the form of
> custom
> >> services.
> >>
> >> I don't think otopi's firewalld plugin is any more complex than the
> >> potential code that will have to be written in vdsm-tool, however it
> >> currently expects the data generated by aforementioned chain. The hybrid
> >> approach briefly touches on simplifying Engine's involvement while
> retaining
> >> use of otopi's plugin.
> >>
> >
> > Okay. I think that writing a new plugin for firewalld is indeed a good
> > option, whether you "refactor" the engine side or not.
>
> otopi already has a 'firewalld' plugin. It's already in use, at least
> by engine-setup, so we should be a bit careful if we want to change it.
> Not preventing/objecting anything, just mentioning.
>
> This plugin's interface currently only takes XML-content as input.
> It has no place for configuring existing firewalld services presumably
> already provided elsewhere (by firewalld itself or 3rd party packages,
> such as vdsm). So if we go that route we probably want to extend this
> interface to allow passing service names and rely on them being defined
> elsewhere.
>
> A related issue is that for engine-setup, the _input_ is currently
> firewalld xml content, and if users choose to configure 'iptables',
> this is parsed to generate iptables rules. This is currently an
> engine-setup
> issue only, but will affect also host deploy flow if we decided to
> allow passing service names (without their xml content) and still keep
> compatibility to current state and allow configuring iptables on the
> host. We'll then be there in the same situation we are at with
> engine-setup.
> See also https://bugzilla.redhat.com/1432354 . An alternative is obviously
> deciding to remove iptables support and support only firewalld, but this
> is a rather radical change for users, imo.
>
> See also this for some of the existing behavior of engine-setup:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1024707#c9
>
> IMO we first need to decide what we want, then how to do that. IMO the
> questions we have re "what we want" are, more-or-less:
>
> 1. Do we want to support in some version X both iptables and firewalld, or
> is it ok to stop support for iptables and support only firewalld without
> overlap? If so, do we handle upgrades, and how?
>
> 2. Do we want to support custom firewalld xml to be co

[ovirt-devel] [VDSM] storage_iscsi_test.RescanTimeoutTests test failing

[Edward Haas]

I got this test failing on one of the builds:
(
http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/5266/console
)

*09:39:16* 
==*09:39:16*
FAIL: testTimeout (storage_iscsi_test.RescanTimeoutTests)*09:39:16*
--*09:39:16*
Traceback (most recent call last):*09:39:16*   File
"/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/monkeypatch.py",
line 133, in wrapper*09:39:16* return f(*args, **kw)*09:39:16*
File 
"/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/monkeypatch.py",
line 133, in wrapper*09:39:16* return f(*args, **kw)*09:39:16*
File 
"/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/storage_iscsi_test.py",
line 45, in testTimeout*09:39:16* iscsi.rescan()*09:39:16*   File
"/usr/lib64/python2.7/contextlib.py", line 24, in __exit__*09:39:16*
  self.gen.next()*09:39:16*   File
"/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/storage_iscsi_test.py",
line 33, in assertMaxDuration*09:39:16* (elapsed,
maxtime))*09:39:16* AssertionError: Operation was too slow 1.32s >
1.20s*09:39:16*  >> begin captured logging <<
*09:39:16* 2016-12-26 09:36:46,857 DEBUG
(MainThread) [storage.SamplingMethod] Trying to enter sampling method
(vdsm.storage.iscsi.rescan) (misc:467)*09:39:16* 2016-12-26
09:36:46,857 DEBUG (MainThread) [storage.SamplingMethod] Got in to
sampling method (misc:470)*09:39:16* 2016-12-26 09:36:46,857 DEBUG
(MainThread) [storage.ISCSI] Performing SCSI scan, this will take up
to 1 seconds (iscsi:457)*09:39:16* 2016-12-26 09:36:46,858 DEBUG
(MainThread) [root] /usr/bin/taskset --cpu-list 0-3 sleep 2 (cwd None)
(commands:69)*09:39:16* 2016-12-26 09:36:48,183 DEBUG (MainThread)
[storage.SamplingMethod] Returning last result (misc:477)*09:39:16*
- >> end captured logging << -


I was surprised that it uses a time measurement to determine success.

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

Re: [ovirt-devel] New test failure on travis

[Edward Haas]

On Thu, Dec 8, 2016 at 12:11 PM, Martin Polednik 
wrote:

> On 08/12/16 11:26 +0200, Edward Haas wrote:
>
>> On Thu, Dec 8, 2016 at 10:12 AM, Martin Polednik 
>> wrote:
>>
>> On 08/12/16 09:28 +0200, Edward Haas wrote:
>>>
>>> On Wed, Dec 7, 2016 at 11:54 PM, Nir Soffer  wrote:
>>>>
>>>> broken_on_ci is uses default name="OVIRT_CI", to mark it also for
>>>>
>>>>> travis, we need another broken_on_ci with name="TRAVIS_CI".
>>>>>
>>>>> Maybe this test should run only if nm is active on the machine?
>>>>>
>>>>>
>>>>> We need the test to always run when expected.
>>>> If NM is not running, the test will not run (silently) and we will never
>>>> know if there is a problem or not.
>>>>
>>>> It is not convenient to mark each CI type as broken, why the test code
>>>> needs to know we have multiple
>>>> CI/s?
>>>>
>>>>
>>> I believe this is great point - we should just mark the test as broken
>>> on *any* CI to create a pressure to get it fixed.
>>>
>>> Slight off-topic addition: I don't understand why patch marking a test
>>> as broken on CI takes more than 5 minutes to get merged in when given
>>> pointer to the failure.
>>>
>>
>>
>> Because it is a wrong approach. :)
>> If a test fails, it is a smell that something bad happens and we may have
>> a
>> production problem.
>> So before marking and excluding the test, one should feel very guilty that
>> this check is no longer covered and better understand why it fails.
>>
>
> Those are 1-in-N case breakages. The fact the test is unstable should
> be noted by a maintainer, but shouldn't block any other patches or
> series (which is what often happens).
>
> I don't feel any guilt marking bad test as bad.


How do you know if it is a bad test, bad production code or perhaps even a
bad
3rd party library/driver etc...?
In most cases, the test just checks that what we expect from the code
indeed happens.
If our expectations are not valid, we have a bad test, but if our
expectations are valid, killing
the test just hides the problem.

Regarding the blocking part, I agree, it is indeed a problem. Except
splitting a project into
smaller pieces I don't know of a good solution for that. (introducing other
problems)
(When you are small, you can run faster. I think this is the micro-services
way)


>
>
>
>>
>>>
>>> Currently, we run on CI tests that are not marked as 'functional'.
>>>
>>>> Perhaps we need another test type that can be mark not to run on simple
>>>> CI.
>>>> "power-integration", "super-integration"?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Wed, Dec 7, 2016 at 11:23 PM, Dan Kenigsberg 
>>>>> wrote:
>>>>> > On Wed, Dec 7, 2016 at 2:03 PM, Nir Soffer 
>>>>> wrote:
>>>>> >> Looks like we need @brokentest("reason...", name="TRAVIC_CI") on
>>>>> this:
>>>>> >
>>>>> > Odd, the code already has
>>>>> >
>>>>> > @broken_on_ci('NetworkManager should not be started on CI nodes')
>>>>> >
>>>>> >
>>>>> >>
>>>>> >> See https://travis-ci.org/oVirt/vdsm/jobs/181933329
>>>>> >>
>>>>> >> 
>>>>> ==
>>>>> >>
>>>>> >> ERROR: test suite for >>>> >> '/vdsm/tests/network/nmdbus_test.py'>
>>>>> >>
>>>>> >> 
>>>>> --
>>>>> >>
>>>>> >> Traceback (most recent call last):
>>>>> >>
>>>>> >>   File "/usr/lib/python2.7/site-packages/nose/suite.py", line 209,
>>>>> in
>>>>> run
>>>>> >>
>>>>> >> self.setUp()
>>>>> >>
>>>>> >>   File "/usr/lib/python2.7/site-packages/nose/suite.py", line 292,
>>>>> in
>>>>> setUp
>>>>> >>
>>>>> >> self.setupContext(ancestor)
>>>>> >>
>>>

Re: [ovirt-devel] Heads-up: moving Libvirt xml creation to the engine

[Edward Haas]

On Wed, Nov 23, 2016 at 2:59 PM, Arik Hadas  wrote:

> Hi All,
>
> We are working on something that is expected to have a big impact, hence
> this heads-up.
> First, we want you to be aware of this change and provide your feedback to
> make it as good as possible.
> Second, until the proposed mechanism is fully merged there will be a chase
> to cover all features unless new features are also implemented with the new
> mechanism. So please, if you are working on something that adds/changes
> something in the Libvirt's domain xml, do it with this new mechanism as
> well (first version would be merged soon).
>
> * Goal
> Creating Libvirt XML in the engine rather than in VDSM.
> ** Today's flow
> Engine: VM business entity -> VM properties map
> VDSM:   VM properties map  -> Libvirt XML
> ** Desired flow
> Engine: VM business entity -> Libvirt XML
>
> * Potential Benefits
> 1. Reduce the number of conversions from 2 to 1, reducing chances for
> mistakes in the process.
> 2. Reduce the amount of code in VDSM.
> 3. Make VM related changes easier - today many of these changes need to be
> reviewed in 2 projects, this will eliminate the one that tends to take
> longer.
> 4. Prevent shortcuts in the form of VDSM-only changes that should be
> better reflected in the engine.
> 5. Not to re-generate the XML on each rerun attempt of VM run/migration.
> 6. Future - not to re-generate the XML on each attempt to auto-start HA VM
> when using vm-leases (need to make sure we're using the up-to-date VM
> configuration though).
> 7. We already found improvements and cleanups that could be made while
> touching this area (e.g., remove the boot order from devices in the
> database).
>
> * Challenges
> 1. Not to move host-specific information to the engine. For example, path
> to storage domain or sockets of channels.
>The solution is to use place-holders that will be replaced by VDSM.
> 2. Backward compatibility.
> 3. The more challenging part is the other direction - that will be the
> next phase.
>
> * Status
> As a first step, we began with producing the Libvirt XML in the engine by
> converting the VM properties map to XML in the engine [1]
> And using the XML that is received as an input in VDSM [2]
>
>
> [1] https://gerrit.ovirt.org/#/c/64473/
> [2] https://gerrit.ovirt.org/#/c/65182/
>
> Regards,
> Arik
>

This is an interesting path to take, but centralizing the logic to a single
component often limits and does not allow scaling.
A large amount of solutions these days attempt to distribute work, reducing
central work to a minimum, but this approach suggests the opposite.

In the networking area, from my limited experience, changes are pushed
faster to VDSM compared to Engine.
In many cases it is just logically simpler: Engine needs to handle and be
concern about all the system as a whole, while VDSM just takes care of the
host.
Therefore, in my mind, the goal is to distribute as much as possible to the
edges, keeping in the centre the minimum required to connect then all
together.

This approach will remove a conversion and with it an abstraction layer. I
find abstraction useful, decoupling components and increasing modularity.
As an example from the OvS integration work, changing the underlying
networking implementation should not concern the upper business logic
components,
it should be well hidden in the hypervisor, exposing only capabilities and
nothing more that hints about the what and how.

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

Re: [ovirt-devel] New test failure on travis

[Edward Haas]

On Thu, Dec 8, 2016 at 10:12 AM, Martin Polednik 
wrote:

> On 08/12/16 09:28 +0200, Edward Haas wrote:
>
>> On Wed, Dec 7, 2016 at 11:54 PM, Nir Soffer  wrote:
>>
>> broken_on_ci is uses default name="OVIRT_CI", to mark it also for
>>> travis, we need another broken_on_ci with name="TRAVIS_CI".
>>>
>>> Maybe this test should run only if nm is active on the machine?
>>>
>>>
>> We need the test to always run when expected.
>> If NM is not running, the test will not run (silently) and we will never
>> know if there is a problem or not.
>>
>> It is not convenient to mark each CI type as broken, why the test code
>> needs to know we have multiple
>> CI/s?
>>
>
> I believe this is great point - we should just mark the test as broken
> on *any* CI to create a pressure to get it fixed.
>
> Slight off-topic addition: I don't understand why patch marking a test
> as broken on CI takes more than 5 minutes to get merged in when given
> pointer to the failure.


Because it is a wrong approach. :)
If a test fails, it is a smell that something bad happens and we may have a
production problem.
So before marking and excluding the test, one should feel very guilty that
this check is no longer covered and better understand why it fails.


>
>
> Currently, we run on CI tests that are not marked as 'functional'.
>> Perhaps we need another test type that can be mark not to run on simple
>> CI.
>> "power-integration", "super-integration"?
>>
>>
>>
>>
>>>
>>> On Wed, Dec 7, 2016 at 11:23 PM, Dan Kenigsberg 
>>> wrote:
>>> > On Wed, Dec 7, 2016 at 2:03 PM, Nir Soffer  wrote:
>>> >> Looks like we need @brokentest("reason...", name="TRAVIC_CI") on this:
>>> >
>>> > Odd, the code already has
>>> >
>>> > @broken_on_ci('NetworkManager should not be started on CI nodes')
>>> >
>>> >
>>> >>
>>> >> See https://travis-ci.org/oVirt/vdsm/jobs/181933329
>>> >>
>>> >> 
>>> ==
>>> >>
>>> >> ERROR: test suite for >> >> '/vdsm/tests/network/nmdbus_test.py'>
>>> >>
>>> >> 
>>> --
>>> >>
>>> >> Traceback (most recent call last):
>>> >>
>>> >>   File "/usr/lib/python2.7/site-packages/nose/suite.py", line 209, in
>>> run
>>> >>
>>> >> self.setUp()
>>> >>
>>> >>   File "/usr/lib/python2.7/site-packages/nose/suite.py", line 292, in
>>> setUp
>>> >>
>>> >> self.setupContext(ancestor)
>>> >>
>>> >>   File "/usr/lib/python2.7/site-packages/nose/suite.py", line 315, in
>>> >> setupContext
>>> >>
>>> >> try_run(context, names)
>>> >>
>>> >>   File "/usr/lib/python2.7/site-packages/nose/util.py", line 471, in
>>> try_run
>>> >>
>>> >> return func()
>>> >>
>>> >>   File "/vdsm/tests/testValidation.py", line 191, in wrapper
>>> >>
>>> >> return f(*args, **kwargs)
>>> >>
>>> >>   File "/vdsm/tests/testValidation.py", line 97, in wrapper
>>> >>
>>> >> return f(*args, **kwargs)
>>> >>
>>> >>   File "/vdsm/tests/network/nmdbus_test.py", line 48, in setup_module
>>> >>
>>> >> NMDbus.init()
>>> >>
>>> >>   File "/vdsm/lib/vdsm/network/nm/nmdbus/__init__.py", line 33, in
>>> init
>>> >>
>>> >> NMDbus.bus = dbus.SystemBus()
>>> >>
>>> >>   File "/usr/lib64/python2.7/site-packages/dbus/_dbus.py", line 194,
>>> in __new__
>>> >>
>>> >> private=private)
>>> >>
>>> >>   File "/usr/lib64/python2.7/site-packages/dbus/_dbus.py", line 100,
>>> in __new__
>>> >>
>>> >> bus = BusConnection.__new__(subclass, bus_type,
>>> mainloop=mainloop)
>>> >>
>>> >>   File "/usr/lib64/python2.7/site-packages/dbus/bus.py", line 122, in
>>> __new__
>>> >>
>>> >> bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
>>> >>
>>> >> DBusException: org.freedesktop.DBus.Error.FileNotFound: Failed to
>>> >> connect to socket /var/run/dbus/system_bus_socket: No such file or
>>> >> directory
>>> >>
>>> >>  >> begin captured logging << 
>>> >>
>>> >> 2016-12-07 11:48:33,458 DEBUG (MainThread) [root] /usr/bin/taskset
>>> >> --cpu-list 0-1 /bin/systemctl status NetworkManager (cwd None)
>>> >> (commands:69)
>>> >>
>>> >> 2016-12-07 11:48:33,465 DEBUG (MainThread) [root] FAILED:  =
>>> >> 'Failed to get D-Bus connection: Operation not permitted\n';  = 1
>>> >> (commands:93)
>>> >>
>>> >> 2016-12-07 11:48:33,465 DEBUG (MainThread) [root] /usr/bin/taskset
>>> >> --cpu-list 0-1 /bin/systemctl start NetworkManager (cwd None)
>>> >> (commands:69)
>>> >>
>>> >> 2016-12-07 11:48:33,470 DEBUG (MainThread) [root] FAILED:  =
>>> >> 'Failed to get D-Bus connection: Operation not permitted\n';  = 1
>>> >> (commands:93)
>>> >>
>>> >> - >> end captured logging << -
>>>
>>>
> ___
>> 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

Re: [ovirt-devel] New test failure on travis

[Edward Haas]

On Wed, Dec 7, 2016 at 11:54 PM, Nir Soffer  wrote:

> broken_on_ci is uses default name="OVIRT_CI", to mark it also for
> travis, we need another broken_on_ci with name="TRAVIS_CI".
>
> Maybe this test should run only if nm is active on the machine?
>

We need the test to always run when expected.
If NM is not running, the test will not run (silently) and we will never
know if there is a problem or not.

It is not convenient to mark each CI type as broken, why the test code
needs to know we have multiple
CI/s?

Currently, we run on CI tests that are not marked as 'functional'.
Perhaps we need another test type that can be mark not to run on simple CI.
"power-integration", "super-integration"?



>
>
> On Wed, Dec 7, 2016 at 11:23 PM, Dan Kenigsberg  wrote:
> > On Wed, Dec 7, 2016 at 2:03 PM, Nir Soffer  wrote:
> >> Looks like we need @brokentest("reason...", name="TRAVIC_CI") on this:
> >
> > Odd, the code already has
> >
> > @broken_on_ci('NetworkManager should not be started on CI nodes')
> >
> >
> >>
> >> See https://travis-ci.org/oVirt/vdsm/jobs/181933329
> >>
> >> ==
> >>
> >> ERROR: test suite for  >> '/vdsm/tests/network/nmdbus_test.py'>
> >>
> >> --
> >>
> >> Traceback (most recent call last):
> >>
> >>   File "/usr/lib/python2.7/site-packages/nose/suite.py", line 209, in
> run
> >>
> >> self.setUp()
> >>
> >>   File "/usr/lib/python2.7/site-packages/nose/suite.py", line 292, in
> setUp
> >>
> >> self.setupContext(ancestor)
> >>
> >>   File "/usr/lib/python2.7/site-packages/nose/suite.py", line 315, in
> >> setupContext
> >>
> >> try_run(context, names)
> >>
> >>   File "/usr/lib/python2.7/site-packages/nose/util.py", line 471, in
> try_run
> >>
> >> return func()
> >>
> >>   File "/vdsm/tests/testValidation.py", line 191, in wrapper
> >>
> >> return f(*args, **kwargs)
> >>
> >>   File "/vdsm/tests/testValidation.py", line 97, in wrapper
> >>
> >> return f(*args, **kwargs)
> >>
> >>   File "/vdsm/tests/network/nmdbus_test.py", line 48, in setup_module
> >>
> >> NMDbus.init()
> >>
> >>   File "/vdsm/lib/vdsm/network/nm/nmdbus/__init__.py", line 33, in init
> >>
> >> NMDbus.bus = dbus.SystemBus()
> >>
> >>   File "/usr/lib64/python2.7/site-packages/dbus/_dbus.py", line 194,
> in __new__
> >>
> >> private=private)
> >>
> >>   File "/usr/lib64/python2.7/site-packages/dbus/_dbus.py", line 100,
> in __new__
> >>
> >> bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop)
> >>
> >>   File "/usr/lib64/python2.7/site-packages/dbus/bus.py", line 122, in
> __new__
> >>
> >> bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
> >>
> >> DBusException: org.freedesktop.DBus.Error.FileNotFound: Failed to
> >> connect to socket /var/run/dbus/system_bus_socket: No such file or
> >> directory
> >>
> >>  >> begin captured logging << 
> >>
> >> 2016-12-07 11:48:33,458 DEBUG (MainThread) [root] /usr/bin/taskset
> >> --cpu-list 0-1 /bin/systemctl status NetworkManager (cwd None)
> >> (commands:69)
> >>
> >> 2016-12-07 11:48:33,465 DEBUG (MainThread) [root] FAILED:  =
> >> 'Failed to get D-Bus connection: Operation not permitted\n';  = 1
> >> (commands:93)
> >>
> >> 2016-12-07 11:48:33,465 DEBUG (MainThread) [root] /usr/bin/taskset
> >> --cpu-list 0-1 /bin/systemctl start NetworkManager (cwd None)
> >> (commands:69)
> >>
> >> 2016-12-07 11:48:33,470 DEBUG (MainThread) [root] FAILED:  =
> >> 'Failed to get D-Bus connection: Operation not permitted\n';  = 1
> >> (commands:93)
> >>
> >> - >> end captured logging << -
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] test - test_detect_slow_client failing

[Edward Haas]

http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-x86_64/1933/console

On Sun, Sep 11, 2016 at 11:27 PM, Edward Haas  wrote:

> Looks like another failing test on CI.
>
> *20:01:00* ERROR: test_detect_slow_client(False) 
> (protocoldetectorTests.AcceptorTests)*20:01:00* 
> --*20:01:00*
>  Traceback (most recent call last):*20:01:00*   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/protocoldetectorTests.py",
>  line 113, in tearDown*20:01:00* self.acceptor.stop()*20:01:00*   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/protocoldetector.py",
>  line 211, in stop*20:01:00* self._acceptor.close()*20:01:00*   File 
> "/usr/lib64/python2.7/asyncore.py", line 407, in close*20:01:00* 
> self.del_channel()*20:01:00*   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/yajsonrpc/betterAsyncore.py",
>  line 137, in del_channel*20:01:00* asyncore.dispatcher.del_channel(self, 
> map)*20:01:00*   File "/usr/lib64/python2.7/asyncore.py", line 292, in 
> del_channel*20:01:00* del map[fd]*20:01:00* KeyError: 63
>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] test - test_detect_slow_client failing

[Edward Haas]

Looks like another failing test on CI.

*20:01:00* ERROR: test_detect_slow_client(False)
(protocoldetectorTests.AcceptorTests)*20:01:00*
--*20:01:00*
Traceback (most recent call last):*20:01:00*   File
"/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/tests/protocoldetectorTests.py",
line 113, in tearDown*20:01:00* self.acceptor.stop()*20:01:00*
File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/vdsm/protocoldetector.py",
line 211, in stop*20:01:00* self._acceptor.close()*20:01:00*
File "/usr/lib64/python2.7/asyncore.py", line 407, in close*20:01:00*
   self.del_channel()*20:01:00*   File
"/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_64/vdsm/lib/yajsonrpc/betterAsyncore.py",
line 137, in del_channel*20:01:00*
asyncore.dispatcher.del_channel(self, map)*20:01:00*   File
"/usr/lib64/python2.7/asyncore.py", line 292, in del_channel*20:01:00*
del map[fd]*20:01:00* KeyError: 63
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] new(?) network test failure

[Edward Haas]

On Sun, Sep 11, 2016 at 4:13 PM, Edward Haas  wrote:

>
>
> On Thu, Sep 8, 2016 at 3:19 PM, Dan Kenigsberg  wrote:
>
>> On Thu, Sep 08, 2016 at 02:23:24PM +0300, Nir Soffer wrote:
>> > On Thu, Sep 8, 2016 at 2:20 PM, Nir Soffer  wrote:
>> > > Seen this (new?) failure on master - please check:
>>
>> Please rebase on top of the recent fix
>> of https://gerrit.ovirt.org/63516
>>
>> > >
>> > > http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86
>> _64/216/console
>> > >
>> > > 0:59:51 
>> ==
>> > > 10:59:51 FAIL: test_ip_info (network.netinfo_test.TestNetinfo)
>> > > 10:59:51 
>> --
>> > > 10:59:51 Traceback (most recent call last):
>> > > 10:59:51   File
>> > > "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/
>> vdsm/tests/testValidation.py",
>> > > line 97, in wrapper
>> > > 10:59:51 return f(*args, **kwargs)
>> > > 10:59:51   File
>> > > "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/
>> vdsm/tests/network/netinfo_test.py",
>> > > line 359, in test_ip_info
>> > > 10:59:51 [IPV6_ADDR_CIDR]))
>> > > 10:59:51 AssertionError: Tuples differ: ('192.0.2.2',
>> > > '255.255.255.0',... != ('192.0.2.2', '255.255.255.0',...
>> > > 10:59:51
>> > > 10:59:51 First differing element 2:
>> > > 10:59:51 ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32']
>> > > 10:59:51 ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32', '
>> 192.0.2.3/24']
>> > > 10:59:51
>> > > 10:59:51   ('192.0.2.2',
>> > > 10:59:51'255.255.255.0',
>> > > 10:59:51 -  ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32'
>> <http://198.51.100.11/32%27>],
>> > > 10:59:51 +  ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32',
>> > > '192.0.2.3/24' <http://192.0.2.3/24%27>],
>> > > 10:59:51 ?
>> > > 
>> > > 10:59:51
>> > > 10:59:51['2607:f0d0:1002:51::4/64'])
>> > > 10:59:51  >> begin captured logging <<
>> 
>> > > 10:59:51 2016-09-08 10:59:40,924 DEBUG   [root] (MainThread)
>> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip link add name dummy_GX6CE
>> > > type dummy (cwd None)
>> > > 10:59:51 2016-09-08 10:59:40,944 DEBUG   [root] (MainThread) SUCCESS:
>> > >  = '';  = 0
>> > > 10:59:51 2016-09-08 10:59:40,950 DEBUG   [root] (MainThread)
>> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip link set dev dummy_GX6CE up
>> > > (cwd None)
>> > > 10:59:51 2016-09-08 10:59:40,968 DEBUG   [root] (MainThread) SUCCESS:
>> > >  = '';  = 0
>> > > 10:59:51 2016-09-08 10:59:40,971 DEBUG   [root] (MainThread)
>> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_GX6CE
>> > > 192.0.2.2/24 (cwd None)
>> > > 10:59:51 2016-09-08 10:59:40,988 DEBUG   [root] (MainThread) SUCCESS:
>> > >  = '';  = 0
>> > > 10:59:51 2016-09-08 10:59:40,991 DEBUG   [root] (MainThread)
>> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_GX6CE
>> > > 192.0.2.3/24 (cwd None)
>> > > 10:59:51 2016-09-08 10:59:41,007 DEBUG   [root] (MainThread) SUCCESS:
>> > >  = '';  = 0
>> > > 10:59:51 2016-09-08 10:59:41,010 DEBUG   [root] (MainThread)
>> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_GX6CE
>> > > 198.51.100.9/24 (cwd None)
>> > > 10:59:51 2016-09-08 10:59:41,037 DEBUG   [root] (MainThread) SUCCESS:
>> > >  = '';  = 0
>> > > 10:59:51 2016-09-08 10:59:41,040 DEBUG   [root] (MainThread)
>> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip -6 addr add dev dummy_GX6CE
>> > > 2607:f0d0:1002:51::4/64 (cwd None)
>> > > 10:59:51 2016-09-08 10:59:41,067 DEBUG   [root] (MainThread) SUCCESS:
>> > >  = '';  = 0
>> > > 10:59:51 2016-09-08 10:59:41,071 DEBUG   [root] (MainThread)
>> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev du

Re: [ovirt-devel] [VDSM] new(?) network test failure

[Edward Haas]

On Thu, Sep 8, 2016 at 3:19 PM, Dan Kenigsberg  wrote:

> On Thu, Sep 08, 2016 at 02:23:24PM +0300, Nir Soffer wrote:
> > On Thu, Sep 8, 2016 at 2:20 PM, Nir Soffer  wrote:
> > > Seen this (new?) failure on master - please check:
>
> Please rebase on top of the recent fix
> of https://gerrit.ovirt.org/63516
>
> > >
> > > http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-
> x86_64/216/console
> > >
> > > 0:59:51 
> ==
> > > 10:59:51 FAIL: test_ip_info (network.netinfo_test.TestNetinfo)
> > > 10:59:51 
> --
> > > 10:59:51 Traceback (most recent call last):
> > > 10:59:51   File
> > > "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/
> vdsm/tests/testValidation.py",
> > > line 97, in wrapper
> > > 10:59:51 return f(*args, **kwargs)
> > > 10:59:51   File
> > > "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/
> vdsm/tests/network/netinfo_test.py",
> > > line 359, in test_ip_info
> > > 10:59:51 [IPV6_ADDR_CIDR]))
> > > 10:59:51 AssertionError: Tuples differ: ('192.0.2.2',
> > > '255.255.255.0',... != ('192.0.2.2', '255.255.255.0',...
> > > 10:59:51
> > > 10:59:51 First differing element 2:
> > > 10:59:51 ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32']
> > > 10:59:51 ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32', '
> 192.0.2.3/24']
> > > 10:59:51
> > > 10:59:51   ('192.0.2.2',
> > > 10:59:51'255.255.255.0',
> > > 10:59:51 -  ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32'],
> > > 10:59:51 +  ['192.0.2.2/24', '198.51.100.9/24', '198.51.100.11/32',
> > > '192.0.2.3/24'],
> > > 10:59:51 ?
> > > 
> > > 10:59:51
> > > 10:59:51['2607:f0d0:1002:51::4/64'])
> > > 10:59:51  >> begin captured logging <<
> 
> > > 10:59:51 2016-09-08 10:59:40,924 DEBUG   [root] (MainThread)
> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip link add name dummy_GX6CE
> > > type dummy (cwd None)
> > > 10:59:51 2016-09-08 10:59:40,944 DEBUG   [root] (MainThread) SUCCESS:
> > >  = '';  = 0
> > > 10:59:51 2016-09-08 10:59:40,950 DEBUG   [root] (MainThread)
> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip link set dev dummy_GX6CE up
> > > (cwd None)
> > > 10:59:51 2016-09-08 10:59:40,968 DEBUG   [root] (MainThread) SUCCESS:
> > >  = '';  = 0
> > > 10:59:51 2016-09-08 10:59:40,971 DEBUG   [root] (MainThread)
> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_GX6CE
> > > 192.0.2.2/24 (cwd None)
> > > 10:59:51 2016-09-08 10:59:40,988 DEBUG   [root] (MainThread) SUCCESS:
> > >  = '';  = 0
> > > 10:59:51 2016-09-08 10:59:40,991 DEBUG   [root] (MainThread)
> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_GX6CE
> > > 192.0.2.3/24 (cwd None)
> > > 10:59:51 2016-09-08 10:59:41,007 DEBUG   [root] (MainThread) SUCCESS:
> > >  = '';  = 0
> > > 10:59:51 2016-09-08 10:59:41,010 DEBUG   [root] (MainThread)
> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_GX6CE
> > > 198.51.100.9/24 (cwd None)
> > > 10:59:51 2016-09-08 10:59:41,037 DEBUG   [root] (MainThread) SUCCESS:
> > >  = '';  = 0
> > > 10:59:51 2016-09-08 10:59:41,040 DEBUG   [root] (MainThread)
> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip -6 addr add dev dummy_GX6CE
> > > 2607:f0d0:1002:51::4/64 (cwd None)
> > > 10:59:51 2016-09-08 10:59:41,067 DEBUG   [root] (MainThread) SUCCESS:
> > >  = '';  = 0
> > > 10:59:51 2016-09-08 10:59:41,071 DEBUG   [root] (MainThread)
> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip -4 addr add dev dummy_GX6CE
> > > 198.51.100.11/32 (cwd None)
> > > 10:59:51 2016-09-08 10:59:41,090 DEBUG   [root] (MainThread) SUCCESS:
> > >  = '';  = 0
> > > 10:59:51 2016-09-08 10:59:41,102 DEBUG   [root] (MainThread)
> > > /usr/bin/taskset --cpu-list 0-1 /sbin/ip link del dev dummy_GX6CE (cwd
> > > None)
> > > 10:59:51 2016-09-08 10:59:41,133 DEBUG   [root] (MainThread) SUCCESS:
> > >  = '';  = 0
> > > 10:59:51 - >> end captured logging <<
> -
> >
> > Another instance here:
> > http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-
> x86_64/212/console
> >
> > 0:58:52 
> ==
> > 10:58:52 FAIL: test_ip_info (network.netinfo_test.TestNetinfo)
> > 10:58:52 
> --
> > 10:58:52 Traceback (most recent call last):
> > 10:58:52   File
> > "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/
> vdsm/tests/testValidation.py",
> > line 97, in wrapper
> > 10:58:52 return f(*args, **kwargs)
> > 10:58:52   File
> > "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/
> vdsm/tests/network/netinfo_test.py",
> > line 359, in test_ip_info
> > 10:58:52 [IPV6_ADDR_CIDR]))
> > 10:58:52 AssertionError: Tuples differ: ('192.0.2.2',
> > '255.255.255.0',... != ('192.0.2.2', '255.255.255.0',...
> > 10:58:52
> > 10

Re: [ovirt-devel] [VDSM] Failing networking tests

[Edward Haas]

Thanks, we are tracking this.
If it starts to appear frequently, please let me know.

On Mon, Sep 5, 2016 at 12:11 AM, Nir Soffer  wrote:

> The tests passed after retriggering this build, this is probably a
> timing issue in the tests.
>
> On Sun, Sep 4, 2016 at 11:45 PM, Nir Soffer  wrote:
> > Hi all,
> >
> > These tests seems to fail unrelated builds:
> > http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc24-
> x86_64/1600/console
> >
> > Seen it once, please check.
> >
> > 19:43:05 
> ==
> > 19:43:05 ERROR: test_local_auto_with_dynamic_address_from_ra
> > (network.netinfo_test.TestIPv6Addresses)
> > 19:43:05 
> --
> > 19:43:05 Traceback (most recent call last):
> > 19:43:05   File
> > "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_
> 64/vdsm/tests/testValidation.py",
> > line 97, in wrapper
> > 19:43:05 return f(*args, **kwargs)
> > 19:43:05   File
> > "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_
> 64/vdsm/tests/network/netinfo_test.py",
> > line 419, in test_local_auto_with_dynamic_address_from_ra
> > 19:43:05 IPV6_NETPREFIX_LEN, family=6)
> > 19:43:05   File "/usr/lib64/python2.7/contextlib.py", line 24, in
> __exit__
> > 19:43:05 self.gen.next()
> > 19:43:05   File
> > "/home/jenkins/workspace/vdsm_master_check-patch-fc24-x86_
> 64/vdsm/tests/network/nettestlib.py",
> > line 454, in wait_for_ipv6
> > 19:43:05 raise Exception('IPv6 addresses has not been caught within
> the '
> > 19:43:05 Exception: IPv6 addresses has not been caught within the given
> timeout.
> > 19:43:05
> > 19:43:05  >> begin captured logging <<
> 
> > 19:43:05 2016-09-04 19:42:32,949 DEBUG   [root] (MainThread)
> > /usr/bin/taskset --cpu-list 0-1 /sbin/ip link add name veth_hU8rsgT1oy
> > type veth peer name veth_OgkZCPxdBp (cwd None)
> > 19:43:05 2016-09-04 19:42:32,962 DEBUG   [root] (MainThread) SUCCESS:
> >  = '';  = 0
> > 19:43:05 2016-09-04 19:42:32,965 DEBUG   [root] (MainThread)
> > /usr/bin/taskset --cpu-list 0-1 /usr/sbin/dnsmasq --dhcp-authoritative
> > -p 0 --dhcp-option=3 --dhcp-option=6 -i veth_hU8rsgT1oy -I lo -d
> > --bind-dynamic --enable-ra --dhcp-range=2001:1:1:1::,slaac,2m (cwd
> > None)
> > 19:43:05 2016-09-04 19:42:33,475 DEBUG   [root] (MainThread)
> > /usr/bin/taskset --cpu-list 0-1 /sbin/service iptables status (cwd
> > None)
> > 19:43:05 2016-09-04 19:42:33,501 DEBUG   [root] (MainThread) SUCCESS:
> >  = 'Redirecting to /bin/systemctl status
> > iptables.service\nRunning in chroot, ignoring request.\n';  = 0
> > 19:43:05 2016-09-04 19:42:33,502 DEBUG   [root] (MainThread)
> > /usr/bin/taskset --cpu-list 0-1 /sbin/iptables --wait -I INPUT -i
> > veth_hU8rsgT1oy -p udp --sport 68 --dport 67 -j ACCEPT (cwd None)
> > 19:43:05 2016-09-04 19:42:33,514 DEBUG   [root] (MainThread) SUCCESS:
> >  = '';  = 0
> > 19:43:05 2016-09-04 19:42:33,515 DEBUG   [root] (MainThread)
> > /usr/bin/taskset --cpu-list 0-1 /sbin/iptables --wait -I INPUT -i
> > veth_hU8rsgT1oy -p udp --sport 546 --dport 547 -j ACCEPT (cwd None)
> > 19:43:05 2016-09-04 19:42:33,523 DEBUG   [root] (MainThread) SUCCESS:
> >  = '';  = 0
> > 19:43:05 2016-09-04 19:42:33,525 DEBUG   [root] (MainThread)
> > /usr/bin/taskset --cpu-list 0-1 /sbin/ip link set dev veth_OgkZCPxdBp
> > up (cwd None)
> > 19:43:05 2016-09-04 19:42:33,532 DEBUG   [root] (MainThread) SUCCESS:
> >  = '';  = 0
> > 19:43:05 2016-09-04 19:42:33,533 DEBUG   [root] (MainThread)
> > /usr/bin/taskset --cpu-list 0-1 /sbin/ip link set dev veth_hU8rsgT1oy
> > up (cwd None)
> > 19:43:05 2016-09-04 19:42:33,543 DEBUG   [root] (MainThread) SUCCESS:
> >  = '';  = 0
> > 19:43:05 2016-09-04 19:42:33,543 DEBUG   [root] (MainThread)
> > /usr/bin/taskset --cpu-list 0-1 /sbin/ip -6 addr add dev
> > veth_hU8rsgT1oy 2001:1:1:1::1/64 (cwd None)
> > 19:43:05 2016-09-04 19:42:33,550 DEBUG   [root] (MainThread) SUCCESS:
> >  = '';  = 0
> > 19:43:05 2016-09-04 19:42:53,541 DEBUG   [root] (MainThread) dnsmasq:
> > started, version 2.76 DNS disabled
> > 19:43:05 dnsmasq: compile time options: IPv6 GNU-getopt DBus no-i18n
> > IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect
> > inotify
> > 19:43:05 dnsmasq: warning: interface veth_hU8rsgT1oy does not currently
> exist
> > 19:43:05 dnsmasq-dhcp: router advertisement on 2001:1:1:1::
> > 19:43:05 dnsmasq-dhcp: IPv6 router advertisement enabled
> > 19:43:05 dnsmasq-dhcp: RTR-ADVERT(veth_hU8rsgT1oy) 2001:1:1:1::
> > 19:43:05 dnsmasq-dhcp: RTR-ADVERT(veth_hU8rsgT1oy) 2001:1:1:1::
> > 19:43:05
> > 19:43:05 2016-09-04 19:42:53,542 DEBUG   [root] (MainThread)
> > /usr/bin/taskset --cpu-list 0-1 /sbin/service iptables status (cwd
> > None)
> > 19:43:05 2016-09-04 19:42:53,589 DEBUG   [root] (MainThread) SUCCESS:
> >  = 'Redirecting to /bin/systemctl status
> > iptables.service\nRunning in chroot, ignoring request.\n';  = 0
> > 19:43

Re: [ovirt-devel] OVS-based cluster adding vdsm report 'RTNETLINK answers: File exists' error in supervdsm.log in release 4.0.2

[Edward Haas]

Hi Mark,

This and some other problems have been fixed on the master branch.
I would suggest using the master branch for your tests, at least until the
fixes are back-ported to the 4.0 branch.

Thanks,
Edy.


On Wed, Aug 10, 2016 at 8:34 AM, lifuqiong  wrote:

> Hi,
> I want to test ovs in vdsm of release 4.0.2. And according Petr's
> helpful advice, created an ovs-based cluster and install vdsm to ovirt
> engine. But report a 'RTNETLINK answers: File exists' error as bellows.
>
> It seems that vdsm want to  add a default gw through ' ip -4 route add
> default via 192.168.0.1' ; but of course this gateway already exists, why
> the vdsm will still add the default gateway?
>
>
> Error log:
> 
> 
> -
> MainProcess|jsonrpc.Executor/4::DEBUG::2016-08-02
> 22:35:03,203::commands::68::root::(execCmd) /usr/bin/taskset --cpu-list
> 0-3 /sbin/ip link set dev ovirtmgmt up (cwd None)
> MainProcess|jsonrpc.Executor/4::DEBUG::2016-08-02
> 22:35:03,205::commands::86::root::(execCmd) SUCCESS:  = '';  = 0
> MainProcess|jsonrpc.Executor/4::DEBUG::2016-08-02
> 22:35:03,205::commands::68::root::(execCmd) /usr/bin/taskset --cpu-list
> 0-3 /sbin/ip link set dev p3p1 up (cwd None)
> MainProcess|jsonrpc.Executor/4::DEBUG::2016-08-02
> 22:35:03,207::commands::86::root::(execCmd) SUCCESS:  = '';  = 0
> MainProcess|jsonrpc.Executor/4::DEBUG::2016-08-02
> 22:35:03,207::commands::68::root::(execCmd) /usr/bin/taskset --cpu-list
> 0-3 /sbin/ip addr flush dev ovirtmgmt scope global (cwd None)
> MainProcess|jsonrpc.Executor/4::DEBUG::2016-08-02
> 22:35:03,209::commands::86::root::(execCmd) SUCCESS:  = '';  = 0
> MainProcess|jsonrpc.Executor/4::DEBUG::2016-08-02
> 22:35:03,209::commands::68::root::(execCmd) /usr/bin/taskset --cpu-list
> 0-3 /sbin/ip -4 addr add dev ovirtmgmt 192.168.0.117/255.255.255.0 (cwd
> None)
> MainProcess|jsonrpc.Executor/4::DEBUG::2016-08-02
> 22:35:03,211::commands::86::root::(execCmd) SUCCESS:  = '';  = 0
> MainProcess|jsonrpc.Executor/4::DEBUG::2016-08-02
> 22:35:03,211::commands::68::root::(execCmd) /usr/bin/taskset --cpu-list
> 0-3 /sbin/ip -4 route add default via 192.168.0.1 (cwd None)
> MainProcess|jsonrpc.Executor/4::DEBUG::2016-08-02
> 22:35:03,213::commands::86::root::(execCmd) FAILED:  = 'RTNETLINK
> answers: File exists\n';  = 2
> MainProcess|jsonrpc.Executor/4::DEBUG::2016-08-02
> 22:35:03,213::api::246::root::(setupNetworks) Setting up network
> according to configuration: networks:{u'ovirtmgmt': {'remove': True}},
> bondings:{}, options:{'connectivityCheck': 0, 'inRollback': True}
> MainProcess|jsonrpc.Executor/4::DEBUG::2016-08-02
> 22:35:03,213::api::267::root::(_setup_networks) Validating configuration
> MainProcess|jsonrpc.Executor/4::DEBUG::2016-08-02
> 22:35:03,216::routes::75::root::(get_gateway) The gateway 192.168.0.1 is
> duplicated for the device p3p1
>
> MainProcess|jsonrpc.Executor/4::ERROR::2016-08-02
> 22:35:03,310::supervdsmServer::96::SuperVdsm.ServerCallback::(wrapper)
> Error in setupNetworks
> Traceback (most recent call last):
>   File "/usr/share/vdsm/supervdsmServer", line 94, in wrapper
> res = func(*args, **kwargs)
>   File "/usr/lib/python2.7/site-packages/vdsm/network/api.py", line 248,
> in setupNetworks
> _setup_networks(networks, bondings, options)
>   File "/usr/lib/python2.7/site-packages/vdsm/network/api.py", line 275,
> in _setup_networks
> netswitch.setup(networks, bondings, options, in_rollback)
>   File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__
> self.gen.throw(type, value, traceback)
>   File "/usr/lib/python2.7/site-packages/vdsm/network/api.py", line 199,
> in _rollback
> six.reraise(excType, value, tb)
>   File "/usr/lib/python2.7/site-packages/vdsm/network/api.py", line 182,
> in _rollback
> yield
>   File "/usr/lib/python2.7/site-packages/vdsm/network/api.py", line 275,
> in _setup_networks
> netswitch.setup(networks, bondings, options, in_rollback)
>   File "/usr/lib/python2.7/site-packages/vdsm/network/netswitch.py", line
> 119, in setup
> _setup_ovs(ovs_nets, ovs_bonds, options, in_rollback)
>   File "/usr/lib/python2.7/site-packages/vdsm/network/netswitch.py", line
> 165, in _setup_ovs
> connectivity.check(options)
>   File "/usr/lib/python2.7/site-packages/vdsm/network/netconfpersistence.py",
> line 243, in __exit__
> raise ne.RollbackIncomplete(config_diff, ex_type, ex_value)
> IPRoute2Error: ['RTNETLINK answers: File exists']
>
> ip addr show
> 
> 
> 
>  [root@server117 ~]# ip addr show
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
>valid_lft forever preferred_lft forever

Re: [ovirt-devel] 答复: [ovirt-users] How to add ovs-based VM in version 4.0.2? Thank you

[Edward Haas]

On Wed, Aug 10, 2016 at 5:43 AM, lifuqiong  wrote:

> Hi Petr:
> I found that when I type virsh commands like 'virsh list' in vdsm,
> the system will force me to input username and password, Could I cancel
> this authentication step when I type 'virsh list',  If so , how can I do
> this?
>
> Use read only: virsh -r list


> Thank you
> Mark
>
> -邮件原件-
> 发件人: Petr Horacek [mailto:phora...@redhat.com]
> 发送时间: 2016年8月3日 17:22
> 收件人: lifuqiong
> 抄送: Meni Yakove; Dan Kenigsberg; Michael Burman; devel
> 主题: Re: [ovirt-users] [ovirt-devel] How to add ovs-based VM in version
> 4.0.2? Thank you
>
> Hello,
>
> don't forget you still need latest patches which are not part of
> ovirt-release40 nor ovirt-release-master.
>
> Network setup is handled by supervdsmd.service, logs are located in
> /var/log/vdsm/supervdsm.log. Network API entrypoint is in
> /usr/lib/python2.7/site-packages/vdsm/network/api.py.
>
> 2016-08-03 9:58 GMT+02:00 lifuqiong :
> > Hi petr,
> > I followed your instruction last mail, re-install an Centos 7.2
> 1503(ip:192.168.0.117), and executing 'yum install
> http://plain.resources.ovirt.org/pub/ovirt-4.0-pre/rpm/el7/
> noarch/ovirt-release40-pre.rpm'
> >  On the new system.
> >
> > Creating an cluster using ovs-based network, and install
> > vdsm(192.168.0.117); deploy log shows that meeting an error as
> > follows: But I cann't find out the code which implements the function
> > of setupNetworks,
> >
> > Just find the setupNetwork() function was defined in API.py, what does
> this function do actually, where is the code ? and how to fix this error?
> >
> > jsonrpc.Executor/4::ERROR::2016-08-02
> > 22:35:03,321::__init__::549::jsonrpc.JsonRpcServer::(_handle_request)
> Internal server error Traceback (most recent call last):
> >   File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line
> 544, in _handle_request
> > res = method(**params)
> >   File "/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line 195,
> in _dynamicMethod
> > result = fn(*methodArgs)
> >   File "/usr/share/vdsm/API.py", line 1465, in setupNetworks
> > supervdsm.getProxy().setupNetworks(networks, bondings, options)
> >   File "/usr/lib/python2.7/site-packages/vdsm/supervdsm.py", line 53,
> in __call__
> > return callMethod()
> >   File "/usr/lib/python2.7/site-packages/vdsm/supervdsm.py", line 51,
> in 
> > **kwargs)
> >   File "", line 2, in setupNetworks
> >   File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in
> _callmethod
> > raise convert_to_error(kind, result)
> > IPRoute2Error: ['RTNETLINK answers: File exists']
> >
> >
> > Hope get your help asp.
> > Thank you
> > Mark
> >
> >
> > -邮件原件-
> > 发件人: Petr Horacek [mailto:phora...@redhat.com]
> > 发送时间: 2016年8月3日 1:50
> > 收件人: lifuqiong
> > 抄送: Meni Yakove; Dan Kenigsberg; Michael Burman; devel
> > 主题: Re: 答复: [ovirt-users] [ovirt-devel] How to add ovs-based VM in
> > version 4.0.2? Thank you
> >
> > If everything goes well, it will be in master this week. I don't know
> when it will be part of 4.0.
> >
> > I installed master VDSM patched with
> > https://gerrit.ovirt.org/#/q/topic:ovs_acquire on my host (Fedora 23
> with disabled NetworkManager) and it worked OK. You can try to build it on
> your own [1]. If you hit any problem, feel free to ask.
> >
> > We'd like to go that way, but nothing specific yet.
> >
> > [1] http://www.ovirt.org/develop/developer-guide/vdsm/developers/
> >
> > 2016-08-02 14:15 GMT+02:00 lifuqiong :
> >> Hi Petr,
> >> Thank you
> >> When the patch will merge to master? And when will the vdsm
> will release a version with this patch?
> >> Btw, do you have a plan to support ovs with dpdk or vhost-user
> port?  If so, what's the pipeline?
> >>
> >> Thank you
> >>
> >> -邮件原件-
> >> 发件人: Petr Horacek [mailto:phora...@redhat.com]
> >> 发送时间: 2016年8月2日 19:53
> >> 收件人: lifuqiong
> >> 抄送: Meni Yakove; Dan Kenigsberg; Michael Burman; devel
> >> 主题: Re: [ovirt-users] [ovirt-devel] How to add ovs-based VM in
> >> version 4.0.2? Thank you
> >>
> >> Clean == host that has just NICs, like right after system installation
> (no networks created by VDSM, bridges, bonds, vlans). Anyway, VDSM OVS is
> not able to acquire external NICs yet (the patch is under review and will
> be merged to master soon [1]).
> >>
> >> I would recommend you to wait for VDSM with mentioned patch merged. If
> you cannot wait, you can try to setup ovirtmgmt network manually via
> console (turn down NIC, setup OVS network on top of it). Not sure if this
> would help you.
> >>
> >> [1] https://gerrit.ovirt.org/#/c/60404/29
> >>
> >> 2016-08-02 13:30 GMT+02:00 lifuqiong :
> >>> Hi Petr,
> >>> Thank you for your advice. But what does "Clean hosts" mean,
> >>> as I know now, When you add a clean Host to ovirt engine, the vdsm or
> ovirt node will create a Network named ovirtmgmt, which is an Linux bridge
> network, How do I clean the network? Just delete the lin

Re: [ovirt-devel] Is there some guideline how to replace Linux Bridge with ovs on vdsm?

[Edward Haas]

Hello Mark,

OVS limited support is coming out in the next build (4.0.2), it is in
tech-preview stage.
At the moment, there is no ovs-dpdk integration support.

Thanks,
Edy.

On Wed, Jul 27, 2016 at 10:03 AM, lifuqiong 
wrote:

> Hi,
>
>  I want to using ovs replace with Linux bridge, Is there some
> guideline or advice? If I want to use dpdk vhost-user port, how can I do
> that?
>
>
>
> Thank you
>
> Mark
>
> ___
> 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] [VDSM] Failing tests on fresh install

[Edward Haas]

Hello,

I got the error below when running make check after a fresh install.
Has anyone seen this before?

Thanks,
Edy.

==
ERROR: testAlignedAppend (miscTests.DdWatchCopy)
--
Traceback (most recent call last):
  File "/root/workspace/vdsm/tests/miscTests.py", line 373, in
testAlignedAppend
"/dev/zero", path, None, misc.MEGA, os.stat(path).st_size)
  File "/root/workspace/vdsm/lib/vdsm/storage/misc.py", line 308, in
ddWatchCopy
deathSignal=signal.SIGKILL)
  File "/root/workspace/vdsm/lib/vdsm/commands.py", line 71, in execCmd
deathSignal=deathSignal)
  File "/usr/lib64/python2.7/site-packages/cpopen/__init__.py", line 63, in
__init__
**kw)
  File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
errread, errwrite)
  File "/usr/lib64/python2.7/site-packages/cpopen/__init__.py", line 82, in
_execute_child_v276
restore_sigpipe=restore_sigpipe
  File "/usr/lib64/python2.7/site-packages/cpopen/__init__.py", line 107,
in _execute_child_v275
restore_sigpipe
OSError: [Errno 0] Error
 >> begin captured logging << 
2016-06-28 03:51:05,481 DEBUG   [Storage.Misc.excCmd] (MainThread)
/usr/bin/taskset --cpu-list 0-0 /usr/bin/nice -n 19 /usr/bin/ionice -c 3
/usr/bin/dd if=/dev/zero of=/var/tmp/tmp_HJ3St bs=1048576 seek=1 skip=1
conv=notrunc count=1 oflag=direct (cwd None)
- >> end captured logging << -

--
Ran 2468 tests in 126.028s

FAILED (SKIP=133, errors=1)
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [VDSM] stuck tests in the ci - update

[Edward Haas]

On Wed, Jun 1, 2016 at 1:44 PM, Nir Soffer  wrote:

> Hi all,
>
> So we have this patch, aborting stuck tests and printing a backtrace
> of all threads:
> https://gerrit.ovirt.org/#/c/58212
>
> On fedora, we get now a nice backtrace (see bellow) - which show that
> we have unexpected
> threads running during the tests.
>
> we have 25 iopproces threads like this:
>
> 09:09:20 Thread 34 (Thread 0x7fb5ab7fe700 (LWP 49858)):
> 09:09:20 Traceback (most recent call first):
> 09:09:20   File
> "/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 222, in
> NoIntrPoll
> 09:09:20 return pollfun(timeout * 1000)  # timeout for poll is in ms
> 09:09:20   File
> "/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 115, in
> _communicate
> 09:09:20 pollres = NoIntrPoll(poller.poll, 5)
> 09:09:20   File "/usr/lib64/python2.7/threading.py", line 757, in run
> 09:09:20 self.__target(*self.__args, **self.__kwargs)
> 09:09:20   File "/usr/lib64/python2.7/threading.py", line 804, in
> __bootstrap_inner
> 09:09:20 self.run()
> 09:09:20   File "/usr/lib64/python2.7/threading.py", line 777, in
> __bootstrap
> 09:09:20 self.__bootstrap_inner()
>
> This is expected given the current code managing these, and are daemon
> threads.
>
> We have 8 reactor threads:
>
> 09:09:20 Thread 32 (Thread 0x7fb58effd700 (LWP 50091)):
> 09:09:20 Traceback (most recent call first):
> 09:09:20   File "/usr/lib64/python2.7/asyncore.py", line 192, in poll2
> 09:09:20 r = pollster.poll(timeout)
> 09:09:20   File "/usr/lib64/python2.7/asyncore.py", line 220, in loop
> 09:09:20 poll_fun(timeout, map)
> 09:09:20   File
>
> "/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/lib/yajsonrpc/betterAsyncore.py",
> line 212, in process_requests
> 09:09:20 count=1,
> 09:09:20   File "/usr/lib64/python2.7/threading.py", line 757, in run
> 09:09:20 self.__target(*self.__args, **self.__kwargs)
> 09:09:20   File "/usr/lib64/python2.7/threading.py", line 804, in
> __bootstrap_inner
> 09:09:20 self.run()
> 09:09:20   File "/usr/lib64/python2.7/threading.py", line 777, in
> __bootstrap
> 09:09:20 self.__bootstrap_inner()
>
> I don't know where these are started and it they are daemon threads.
>
> Searching the tests, we have too much code creating threads directly,
> instead of using vdsm.concurrent.thread:
>
> $ git grep Thread tests/ | wc -l
> 79
>
> Please check your tests, and replace all threads to use
> testlib.start_thread()
> creating daemon threads.
>
> Code inheriting from threading.Thread is the worst, please keep a thread
> instance instead, and start it with testlib.start_thread().
>
> I sent this patch fixing sslTests for now:
> https://gerrit.ovirt.org/58435
>
> Nir
>
> 
>
> 09:06:05 testlibTests.TestStuckProcess
> 09:09:19 test_stuck
> 09:09:19
> 
> 09:09:19 =   Timeout completing tests - extracting stacktrace
>  =
> 09:09:19
> 
> 09:09:19
> 09:09:19 attach: No such file or directory.
> 09:09:19 [New LWP 50476]
> 09:09:19 [New LWP 50469]
> 09:09:19 [New LWP 50462]
> 09:09:19 [New LWP 50455]
> 09:09:19 [New LWP 50448]
> 09:09:19 [New LWP 50441]
> 09:09:19 [New LWP 50434]
> 09:09:19 [New LWP 50427]
> 09:09:19 [New LWP 50420]
> 09:09:19 [New LWP 50413]
> 09:09:19 [New LWP 50406]
> 09:09:19 [New LWP 50399]
> 09:09:19 [New LWP 50392]
> 09:09:19 [New LWP 50385]
> 09:09:19 [New LWP 50378]
> 09:09:19 [New LWP 50371]
> 09:09:19 [New LWP 50364]
> 09:09:19 [New LWP 50247]
> 09:09:19 [New LWP 50240]
> 09:09:19 [New LWP 50233]
> 09:09:19 [New LWP 50226]
> 09:09:19 [New LWP 50219]
> 09:09:19 [New LWP 50216]
> 09:09:19 [New LWP 50189]
> 09:09:19 [New LWP 50175]
> 09:09:19 [New LWP 50161]
> 09:09:19 [New LWP 50147]
> 09:09:19 [New LWP 50133]
> 09:09:19 [New LWP 50119]
> 09:09:19 [New LWP 50105]
> 09:09:19 [New LWP 50091]
> 09:09:19 [New LWP 49889]
> 09:09:19 [New LWP 49858]
> 09:09:19 [Thread debugging using libthread_db enabled]
> 09:09:19 Using host libthread_db library "/lib64/libthread_db.so.1".
> 09:09:20 0x7fb5ffece8a3 in select () at
> ../sysdeps/unix/syscall-template.S:84
> 09:09:20 84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
> 09:09:20
> 09:09:20 Thread 34 (Thread 0x7fb5ab7fe700 (LWP 49858)):
> 09:09:20 Traceback (most recent call first):
> 09:09:20   File
> "/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 222, in
> NoIntrPoll
> 09:09:20 return pollfun(timeout * 1000)  # timeout for poll is in ms
> 09:09:20   File
> "/usr/lib/python2.7/site-packages/ioprocess/__init__.py", line 115, in
> _communicate
> 09:09:20 pollres = NoIntrPoll(poller.poll, 5)
> 09:09:20   File "/usr/lib64/python2.7/threading.py", line 757, in run
> 09:09:20 self.__target(*self.__args, **self.__kwargs)
> 09:09:20   File "/usr/lib64/python2.7/threading.py", line 804, in
> __bootstrap_inner
> 09:09:20 se

Re: [ovirt-devel] [VDSM] Random network tests failing

[Edward Haas]

On Wed, Jun 1, 2016 at 10:53 PM, Nir Soffer  wrote:

> Seems that random network test fail now in the ci. Did we change
> anything in the infrastructure that can explain this?
>
> This is the same pattern we saw in other tests, all the ip calls are
> successful,
> but the test is not happy.
>
> 18:49:09
> ==
> 18:49:09 FAIL: testDisablePromisc (network.ipwrapper_test.TestDrvinfo)
> 18:49:09
> --
> 18:49:09 Traceback (most recent call last):
> 18:49:09   File
>
> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/network/ipwrapper_test.py",
> line 149, in testDisablePromisc
> 18:49:09 "Could not disable promiscuous mode.")
> 18:49:09 AssertionError: Could not disable promiscuous mode.
> 18:49:09  >> begin captured logging <<
> 
> 18:49:09 2016-06-01 18:48:58,492 DEBUG   [root] (MainThread)
> /usr/bin/taskset --cpu-list 0-1 /usr/sbin/brctl show (cwd None)
> 18:49:09 2016-06-01 18:48:58,501 DEBUG   [root] (MainThread) SUCCESS:
>  = '';  = 0
> 18:49:09 2016-06-01 18:48:58,501 DEBUG   [root] (MainThread)
> /usr/bin/taskset --cpu-list 0-1 /sbin/ip link add name vdsm-Cnvkvg
> type bridge (cwd None)
> 18:49:09 2016-06-01 18:48:58,510 DEBUG   [root] (MainThread) SUCCESS:
>  = '';  = 0
> 18:49:09 2016-06-01 18:48:58,511 DEBUG   [root] (MainThread)
> /usr/bin/taskset --cpu-list 0-1 /sbin/ip link set dev vdsm-Cnvkvg up
> (cwd None)
> 18:49:09 2016-06-01 18:48:58,522 DEBUG   [root] (MainThread) SUCCESS:
>  = '';  = 0
> 18:49:09 2016-06-01 18:48:58,523 DEBUG   [root] (MainThread)
> /usr/bin/taskset --cpu-list 0-1 /sbin/ip link set dev vdsm-Cnvkvg
> promisc on (cwd None)
> 18:49:09 2016-06-01 18:48:58,533 DEBUG   [root] (MainThread) SUCCESS:
>  = '';  = 0
> 18:49:09 2016-06-01 18:48:58,533 DEBUG   [root] (MainThread)
> /usr/bin/taskset --cpu-list 0-1 /sbin/ip link set dev vdsm-Cnvkvg
> promisc off (cwd None)
> 18:49:09 2016-06-01 18:48:58,542 DEBUG   [root] (MainThread) SUCCESS:
>  = '';  = 0
>

How often has this been seen? Is this failing on a specific platform?

This is an integration test that should be run on a VM.
We should target for running the CI integration tests with lago and a
dedicated VDSM (for test) image.

If this failure will occur too often, we can label it such that it will not
run on CI. (but will run locally)

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

Re: [ovirt-devel] [vdsm] Another network test failing

[Edward Haas]

On Tue, May 10, 2016 at 8:19 PM, Adam Litke  wrote:

> On 10/05/16 18:08 +0300, Dan Kenigsberg wrote:
>
>> On Mon, May 09, 2016 at 02:48:43PM -0400, Adam Litke wrote:
>>
>>> When running make check on my local system I often (but not always)
>>> get the following error:
>>>
>>
>> Do you have any clue related to when this happens? (your pwd,
>> pythonpath)
>>
>
> Maybe it's a side effect of the way nose loads and runs tests?
>
> Did it begin with the recent move of netinfo under vdsm.network?
>> https://gerrit.ovirt.org/56713 (CommitDate: Thu May 5) or did you see it
>> earlier?
>>
>
> That's possible.  It only started happening recently.  It seems to
> fail only when run under 'make check' but not when run via
> ./run_tests_local.sh.


Is it possible that on the same machine you have installed an older vdsm
version
and it somehow conflicts? (resolving vdsm from the site-packages instead
from
the local workspace)


>
>
>>
>>
>>> $ rpm -qa | grep libvirt-python
>>> libvirt-python-1.2.18-1.fc23.x86_64
>>>
>>> 
>>>
>>> ==
>>> ERROR: Failure: ImportError (No module named 'libvirt')
>>> --
>>> Traceback (most recent call last):
>>>  File "/usr/lib/python3.4/site-packages/nose/failure.py", line 39, in
>>> runTest
>>>raise self.exc_val.with_traceback(self.tb)
>>>  File "/usr/lib/python3.4/site-packages/nose/loader.py", line 418, in
>>> loadTestsFromName
>>>addr.filename, addr.module)
>>>  File "/usr/lib/python3.4/site-packages/nose/importer.py", line 47,
>>> in importFromPath
>>>return self.importFromDir(dir_path, fqname)
>>>  File "/usr/lib/python3.4/site-packages/nose/importer.py", line 94,
>>> in importFromDir
>>>mod = load_module(part_fqname, fh, filename, desc)
>>>  File "/usr/lib64/python3.4/imp.py", line 235, in load_module
>>>return load_source(name, filename, file)
>>>  File "/usr/lib64/python3.4/imp.py", line 171, in load_source
>>>module = methods.load()
>>>  File "", line 1220, in load
>>>  File "", line 1200, in _load_unlocked
>>>  File "", line 1129, in _exec
>>>  File "", line 1471, in exec_module
>>>  File "", line 321, in
>>> _call_with_frames_removed
>>>  File "/home/alitke/src/vdsm/tests/network/models_test.py", line 27,
>>> in 
>>>from vdsm.network.netinfo import bonding, mtus
>>>  File "/home/alitke/src/vdsm/lib/vdsm/network/netinfo/__init__.py",
>>> line 26, in 
>>>from vdsm import libvirtconnection
>>>  File "/home/alitke/src/vdsm/lib/vdsm/libvirtconnection.py", line 29,
>>> in 
>>>import libvirt
>>> ImportError: No module named 'libvirt'
>>>
>>> --
>>> Ran 234 tests in 11.084s
>>>
>>> FAILED (SKIP=42, errors=1)
>>>
>>
> --
> Adam Litke
>
> ___
> 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

Re: [ovirt-devel] python-mock

[Edward Haas]

On Wed, Apr 6, 2016 at 3:22 PM, Eyal Edri  wrote:

> My only guess would be old VDSM functional tests or unit test using mock.
> Yaniv/Danken?
>
> e.
>
> On Wed, Apr 6, 2016 at 2:40 PM, Shlomi Ben David 
> wrote:
>
>> Hi,
>>
>> I wanted to ask you if you know about a Jenkins job that is using
>> 'python-mock' pkg? if you do please let me know.
>>
>> Thanks in advanced,
>>
>> --
>> Shlomi Ben-David | Software Engineer | Red Hat ISRAEL
>>
>> OPEN SOURCE - 1 4 011 && 011 4 1
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>
>
> --
> Eyal Edri
> Associate Manager
> RHEV DevOps
> EMEA ENG Virtualization R&D
> Red Hat Israel
>
> 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
>


VDSM is currently not using it, but a proposal to use it has been raised:
https://gerrit.ovirt.org/#/c/55342/
It is a powerful mocking library that has been added to python3.

It will be nice to hear how others use it and why.

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

Re: [ovirt-devel] [vdsm] Running VDSM unit tests on Travis CI using Docker

[Edward Haas]

On Wed, Apr 6, 2016 at 2:41 PM, Nir Soffer  wrote:

> On Wed, Apr 6, 2016 at 2:33 PM, Edward Haas  wrote:
> >
> >
> > On Wed, Apr 6, 2016 at 2:23 PM, Nir Soffer  wrote:
> >>
> >> On Wed, Apr 6, 2016 at 2:19 PM, Edward Haas  wrote:
> >> >
> >> >
> >> > On Wed, Apr 6, 2016 at 1:41 PM, Milan Zamazal 
> >> > wrote:
> >> >>
> >> >> Edward Haas  writes:
> >> >>
> >> >> > On Wed, Apr 6, 2016 at 11:39 AM, Milan Zamazal <
> mzama...@redhat.com>
> >> >> > wrote:
> >> >> >
> >> >> > Thank you, Edward, this is useful not only for CI. I use docker
> >> >> > for
> >> >> > building Vdsm and running its unit tests and this helped me to
> >> >> > get
> >> >> > the
> >> >> > proper updated set of packages after recent changes in Vdsm.
> >> >> >
> >> >> > BTW, it seems that the following packages should be
> additionally
> >> >> > added
> >> >> > for `make check-all': psmisc, which, python-ioprocess
> >> >> >
> >> >> >
> >> >> > Are you saying that make check is passing on your local machine?
> >> >>
> >> >> When I add the packages given above, `make check-all' (as well as
> `make
> >> >> check') works for me except for 4 tests in lib/vdsm/schedule.py that
> >> >> produce the following errors with `make check-all':
> >> >>
> >> >> File "/home/pdm/ovirt/vdsm/vdsm-test/lib/vdsm/schedule.py", line
> >> >> 134,
> >> >> in schedule
> >> >>   heapq.heappush(self._calls, (deadline, call))
> >> >>   nose.proxy.TypeError: unorderable types: ScheduledCall() <
> >> >> ScheduledCall()
> >> >>
> >> >> File "/home/pdm/ovirt/vdsm/vdsm-test/tests/scheduleTests.py",
> line
> >> >> 160, in test_latency
> >> >>   med = ticker.latency[len(ticker.latency) / 2]
> >> >>   nose.proxy.TypeError: list indices must be integers, not float
> >> >>
> >> >> Those are probably Python 3 failures that should be fixed in Vdsm.
> >> >> The docker environment works fine for running the unit tests on my
> >> >> machine.
> >> >
> >> >
> >> > I ran it on Travis CI with your recommended addition, and I am getting
> >> > this
> >> > result: FAILED (SKIP=107, errors=14):
> >> > You can view the run here:
> >> > https://travis-ci.org/EdDev/vdsm/builds/121117253
> >>
> >> Sure, make check in master run tests that should not run on travis.
> >>
> >> Try the travis branch - after adding ioprocess to the docker image,
> >> all tests should pass:
> >> https://gerrit.ovirt.org/55738
> >>
> >> Nir
> >
> >
> > Ok, will check it as well.
> > But its a bit of a lie, many tests are skipped instead of not ran at all,
> > this needs to be fixed.
> > In addition, I find many tests as not unit tests, all tests should pass
> in a
> > few seconds not in 2 minutes.
>
> Storage people always lie :-)
>
> We have @slowtest for marking slow tests. Unfortunately, some tests are
> slow, and there is no value in mocking the thing you want to test.
>
> Nir
>

Well, I will like to run only the unit tests, and you seem to try and merge
the integration tests
in the same run. I think they need to be separated.
I would like to see the unit tests pass in a few seconds, have no
surprising skips and
have no dependency or other services.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [vdsm] Running VDSM unit tests on Travis CI using Docker

[Edward Haas]

On Wed, Apr 6, 2016 at 2:23 PM, Nir Soffer  wrote:

> On Wed, Apr 6, 2016 at 2:19 PM, Edward Haas  wrote:
> >
> >
> > On Wed, Apr 6, 2016 at 1:41 PM, Milan Zamazal 
> wrote:
> >>
> >> Edward Haas  writes:
> >>
> >> > On Wed, Apr 6, 2016 at 11:39 AM, Milan Zamazal 
> >> > wrote:
> >> >
> >> > Thank you, Edward, this is useful not only for CI. I use docker
> for
> >> > building Vdsm and running its unit tests and this helped me to get
> >> > the
> >> > proper updated set of packages after recent changes in Vdsm.
> >> >
> >> > BTW, it seems that the following packages should be additionally
> >> > added
> >> > for `make check-all': psmisc, which, python-ioprocess
> >> >
> >> >
> >> > Are you saying that make check is passing on your local machine?
> >>
> >> When I add the packages given above, `make check-all' (as well as `make
> >> check') works for me except for 4 tests in lib/vdsm/schedule.py that
> >> produce the following errors with `make check-all':
> >>
> >> File "/home/pdm/ovirt/vdsm/vdsm-test/lib/vdsm/schedule.py", line
> 134,
> >> in schedule
> >>   heapq.heappush(self._calls, (deadline, call))
> >>   nose.proxy.TypeError: unorderable types: ScheduledCall() <
> >> ScheduledCall()
> >>
> >> File "/home/pdm/ovirt/vdsm/vdsm-test/tests/scheduleTests.py", line
> >> 160, in test_latency
> >>   med = ticker.latency[len(ticker.latency) / 2]
> >>   nose.proxy.TypeError: list indices must be integers, not float
> >>
> >> Those are probably Python 3 failures that should be fixed in Vdsm.
> >> The docker environment works fine for running the unit tests on my
> >> machine.
> >
> >
> > I ran it on Travis CI with your recommended addition, and I am getting
> this
> > result: FAILED (SKIP=107, errors=14):
> > You can view the run here:
> https://travis-ci.org/EdDev/vdsm/builds/121117253
>
> Sure, make check in master run tests that should not run on travis.
>
> Try the travis branch - after adding ioprocess to the docker image,
> all tests should pass:
> https://gerrit.ovirt.org/55738
>
> Nir
>

Ok, will check it as well.
But its a bit of a lie, many tests are skipped instead of not ran at all,
this needs to be fixed.
In addition, I find many tests as not unit tests, all tests should pass in
a few seconds not in 2 minutes.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [vdsm] Running VDSM unit tests on Travis CI using Docker

[Edward Haas]

On Wed, Apr 6, 2016 at 2:23 PM, David Caro  wrote:

> On 04/06 14:19, Edward Haas wrote:
> > On Wed, Apr 6, 2016 at 1:41 PM, Milan Zamazal 
> wrote:
> >
> > > Edward Haas  writes:
> > >
> > > > On Wed, Apr 6, 2016 at 11:39 AM, Milan Zamazal 
> > > wrote:
> > > >
> > > > Thank you, Edward, this is useful not only for CI. I use docker
> for
> > > > building Vdsm and running its unit tests and this helped me to
> get
> > > the
> > > > proper updated set of packages after recent changes in Vdsm.
> > > >
> > > > BTW, it seems that the following packages should be additionally
> > > added
> > > > for `make check-all': psmisc, which, python-ioprocess
> > > >
> > > >
> > > > Are you saying that make check is passing on your local machine?
> > >
> > > When I add the packages given above, `make check-all' (as well as `make
> > > check') works for me except for 4 tests in lib/vdsm/schedule.py that
> > > produce the following errors with `make check-all':
> > >
> > > File "/home/pdm/ovirt/vdsm/vdsm-test/lib/vdsm/schedule.py", line
> 134,
> > > in schedule
> > >   heapq.heappush(self._calls, (deadline, call))
> > >   nose.proxy.TypeError: unorderable types: ScheduledCall() <
> > > ScheduledCall()
> > >
> > > File "/home/pdm/ovirt/vdsm/vdsm-test/tests/scheduleTests.py", line
> > > 160, in test_latency
> > >   med = ticker.latency[len(ticker.latency) / 2]
> > >   nose.proxy.TypeError: list indices must be integers, not float
> > >
> > > Those are probably Python 3 failures that should be fixed in Vdsm.
> > > The docker environment works fine for running the unit tests on my
> > > machine.
> > >
> >
> > I ran it on Travis CI with your recommended addition, and I am getting
> this
> > result: FAILED (SKIP=107, errors=14):
> > You can view the run here:
> https://travis-ci.org/EdDev/vdsm/builds/121117253
>
>
> Afaik, you won't be able to run any tests that touch networking, or kernel
> modules (bonding and such). That is as much a limitation of travis as of
> docker, that was one of the points why we started using chroots instead of
> docker containers on ovirt ci.
>

Yes, that is why I intended it for unit tests only, not for integration or
functional.
We may find some integration tests that do pass, that needs some more
investigation, but it's out of my original intent
.

>
>
> > ___
> > Devel mailing list
> > Devel@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>
>
> --
> David Caro
>
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>
> Tel.: +420 532 294 605
> Email: dc...@redhat.com
> IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> Web: www.redhat.com
> RHT Global #: 82-62605
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [vdsm] Running VDSM unit tests on Travis CI using Docker

[Edward Haas]

On Wed, Apr 6, 2016 at 1:41 PM, Milan Zamazal  wrote:

> Edward Haas  writes:
>
> > On Wed, Apr 6, 2016 at 11:39 AM, Milan Zamazal 
> wrote:
> >
> > Thank you, Edward, this is useful not only for CI. I use docker for
> > building Vdsm and running its unit tests and this helped me to get
> the
> > proper updated set of packages after recent changes in Vdsm.
> >
> > BTW, it seems that the following packages should be additionally
> added
> > for `make check-all': psmisc, which, python-ioprocess
> >
> >
> > Are you saying that make check is passing on your local machine?
>
> When I add the packages given above, `make check-all' (as well as `make
> check') works for me except for 4 tests in lib/vdsm/schedule.py that
> produce the following errors with `make check-all':
>
> File "/home/pdm/ovirt/vdsm/vdsm-test/lib/vdsm/schedule.py", line 134,
> in schedule
>   heapq.heappush(self._calls, (deadline, call))
>   nose.proxy.TypeError: unorderable types: ScheduledCall() <
> ScheduledCall()
>
> File "/home/pdm/ovirt/vdsm/vdsm-test/tests/scheduleTests.py", line
> 160, in test_latency
>   med = ticker.latency[len(ticker.latency) / 2]
>   nose.proxy.TypeError: list indices must be integers, not float
>
> Those are probably Python 3 failures that should be fixed in Vdsm.
> The docker environment works fine for running the unit tests on my
> machine.
>

I ran it on Travis CI with your recommended addition, and I am getting this
result: FAILED (SKIP=107, errors=14):
You can view the run here: https://travis-ci.org/EdDev/vdsm/builds/121117253
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel