[ovirt-devel] Re: AddClusterCommand is failing

[Piotr Kliczewski]

On Thu, Mar 26, 2020 at 12:26 PM Shmuel Melamud  wrote:

> Hi!
>
> On Thu, Mar 26, 2020 at 12:24 PM Steven Rosenberg 
> wrote:
> > Michal Skrivanek would like to remove the function from the
> AddClusterCommand altogether and leave it null until the first Host is up
> on a cluster.
>
> But cluster's biosType is needed for creating and configuring VMs that
> have CLUSTER_DEFAULT biosType. And VMs may be added to a cluster that
> has no hosts.
>

Here is where we call AddCluster [0] and this code worked before mentioned
patch.

[0]
https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/provider/cluster/KubevirtProviderProxy.java#L189


>
> Shmuel
>
>
___
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/GIQSOV3X3ITRVKTS6B5MZZY5TN6KAVVM/

[ovirt-devel] AddClusterCommand is failing

[Piotr Kliczewski]

Hi,

I posted revert [0] of commit [1] due to the issue with AddClusterCommand
which fails for Adding new Kubevirt provider with:

ERROR: null value in column "bios_type" violates not-null constraint

I am happy to see different solution than revet but at the moment add
cluster is not working.

Thanks,
Piotr

[0] https://gerrit.ovirt.org/#/c/107928/
[1] 6b1d1e3099879d6991401dd545338f7a856fc426
___
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/AMYRVJEWSNDJWWLBBRYL3NT2ZI7XV6PK/

[ovirt-devel] Re: Missing java-client-kubevirt dependency for ovirt-engine

[Piotr Kliczewski]

On Thu, Jan 30, 2020 at 12:10 PM Sandro Bonazzola 
wrote:

>
>
> Il giorno gio 30 gen 2020 alle ore 10:25 Piotr Kliczewski <
> pklic...@redhat.com> ha scritto:
>
>> Sandro,
>>
>> Can you please take a look? How can I make sure that changes like that
>> are included in the future?
>>
>
> Change got stuck in OST and didn't got published.
> I will forcefully push it into tested repo.
>

Thank you!


>
>
>
>>
>> Thanks,
>> Piotr
>>
>> On Thu, Jan 30, 2020 at 10:21 AM Andrej Krejcir 
>> wrote:
>>
>>> Hi,
>>>
>>> Installing the latest ovirt-engine master requires package:
>>> java-client-kubevirt >= 0.2.0
>>>
>>> But the master nightly snapshot contains only version:
>>> java-client-kubevirt-0.1.0-1.20200102130005.git0e3be11
>>>
>>> On the patch that bumped the version, there is a comment from the CI,
>>> that the change was not included in nightly builds:
>>> https://gerrit.ovirt.org/#/c/106499/
>>>
>>>
>>> Best regards,
>>> Andrej
>>>
>>
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA <https://www.redhat.com/>
>
> sbona...@redhat.com
> <https://www.redhat.com/>*Red Hat respects your work life balance.
> Therefore there is no need to answer this email out of your office hours.
> <https://mojo.redhat.com/docs/DOC-1199578>*
>
___
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/LSJTUSYNLSVDGVCS3T5UUMAALSN64XI4/

[ovirt-devel] Re: Missing java-client-kubevirt dependency for ovirt-engine

[Piotr Kliczewski]

Sandro,

Can you please take a look? How can I make sure that changes like that are
included in the future?

Thanks,
Piotr

On Thu, Jan 30, 2020 at 10:21 AM Andrej Krejcir  wrote:

> Hi,
>
> Installing the latest ovirt-engine master requires package:
> java-client-kubevirt >= 0.2.0
>
> But the master nightly snapshot contains only version:
> java-client-kubevirt-0.1.0-1.20200102130005.git0e3be11
>
> On the patch that bumped the version, there is a comment from the CI, that
> the change was not included in nightly builds:
> https://gerrit.ovirt.org/#/c/106499/
>
>
> Best regards,
> Andrej
>
___
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/EJOVJ7TVV5RVO4SZYT24RHADRXEGZ6O4/

[ovirt-devel] ovirt-engine has been tagged (ovirt-engine-4.3.7.0)

[Piotr Kliczewski]

___
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/DWYDVI6YOOB3JLZYM2NV2C7HTEIEBRRJ/

[ovirt-devel] Re: [ OST Failure Report ] [ oVirt 4.3 (vdsm-jsonrpc-java) ] [ 10-3-19 ] [ Upgrade Suite ]

[Piotr Kliczewski]

Liora,

I am not sure what is the failure. Where can I find the logs?

There were no patches to jsonrpc. I only updated expired certs used by unit
tests.

Thanks,
Piotr

niedz., 10 mar 2019, 17:00 użytkownik Liora Milbaum 
napisał:

> Link and headline of suspected patches:
>
> Link to Job:
> http://jenkins.ovirt.org/job/ovirt-4.3_change-queue-tester/153/
>
> Link to all logs:
>
> (Relevant) error snippet from the log:
>
> 
> [36m # 001_upgrade_engine.test_initialize_engine: [0m [0m [0m
> [36m * Copy
> /home/jenkins/workspace/ovirt-4.3_change-queue-tester/ovirt-system-tests/upgrade-from-prevrelease-suite-4.3/upgrade-engine-answer-file.conf
> to lago-upgrade-from-prevrelease-suite-4-3-engine:/tmp/answer-file-post:
> [0m [0m [0m
> [36m * Copy
> /home/jenkins/workspace/ovirt-4.3_change-queue-tester/ovirt-system-tests/upgrade-from-prevrelease-suite-4.3/upgrade-engine-answer-file.conf
> to lago-upgrade-from-prevrelease-suite-4-3-engine:/tmp/answer-file-post:
> [32mSuccess [0m (in 0:00:00) [0m
> [36m * Collect artifacts: [0m [0m [0m
> [36m ~ [Thread-8] Copy from
> lago-upgrade-from-prevrelease-suite-4-3-engine:/tmp/otopi* to
> /dev/shm/ost/deployment-upgrade-from-prevrelease-suite-4.3/default/test_logs/001_upgrade_engine.test_initialize_engine-20190307160642/lago-upgrade-from-prevrelease-suite-4-3-engine/_tmp_otopi*:
> [31mERROR [0m (in 0:00:00) [0m
> [36m - [Thread-8] lago-upgrade-from-prevrelease-suite-4-3-engine:
> [31mERROR [0m (in 0:00:00) [0m
> [36m * Collect artifacts: [31mERROR [0m (in 0:00:01) [0m
> [36m # 001_upgrade_engine.test_initialize_engine: [31mERROR [0m (in
> 0:00:49) [0m
> [36m # Results located at
> /dev/shm/ost/deployment-upgrade-from-prevrelease-suite-4.3/001_upgrade_engine.py.junit.xml
> [0m
> [36m@ Run test: 001_upgrade_engine.py: [31mERROR [0m (in 0:00:49) [0m
> [31mError occured, aborting
> Traceback (most recent call last):
> File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 383, in
> do_run
> self.cli_plugins[args.ovirtverb].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 549, in wrapper
> return func(*args, **kwargs)
> File "/usr/lib/python2.7/site-packages/lago/utils.py", line 560, in wrapper
> return func(*args, prefix=prefix, **kwargs)
> File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 107, in
> do_ovirt_runtest
> raise RuntimeError('Some tests failed')
> RuntimeError: Some tests failed [0m
>
> 
>
>
> --
> *Liora Milbaum*
> Senior Principal Software Engineer
> RHV/CNV DevOps
> EMEA VIRTUALIZATION R
>
> T: +972-54-6560051
> 
>
>
>
>
>
___
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/NDAQAEJBIADJZSSMKACM37UTDJV5LFZD/

[ovirt-devel] ovirt-engine has been tagged (ovirt-engine-4.3.0.1)

[Piotr Kliczewski]

___
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/ZA5PONQARAJAEOK7JA7ADT2PU5MCWQ4M/

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

[Piotr Kliczewski]

Awsome job! Thank you!

śr., 12 gru 2018, 22:41: Dan Kenigsberg  napisał(a):

>
>
> On Wed, 12 Dec 2018, 22:42 Marcin Sobczyk 
>> 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 indeed. I was not aware there's a way to add such parameters to
> suites. It could come up handy elsewhere (e.g. choosing ovs for cluster
> switchtype)
>
> I think it is important to explain why it's so important.
>
> Unfortunately, much of vdsm functionalily is not covered by proper vdsm
> unit tests. We depend on OST to define what is a "working" ovirt.
>
> Here's a message for us vdsm developers: if you care for your code and the
> time you've invested into it, make sure that it shows up green on the likes
> of
> https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-tests_manual/3754/artifact/exported-artifacts/coverage/vdsm/html/index.html
>
> The total number - 59% - is not brilliant, but not as bad as I assumed.
>
> Please go over the report. There are glaring missing pieces (e.g gluster,
> fencing) but also less obvious ones (almost half of vm.py).
>
> It should give you ideas about tests you need to add, or code you can drop.
>
>
___
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/KH7WUU4G43W2HCNUFGC4F2DNIHAVOTTF/

[ovirt-devel] Fwd: [ovirt-users] FOSDEM‘19 Virtualization & IaaS Devroom CfP

[Piotr Kliczewski]

A friendly reminder that Cfp is due by 1st of December.

Please submit your proposal using:

https://penta.fosdem.org/submission/FOSDEM19

-- Forwarded message -
From: Piotr Kliczewski 
Date: Tue, Oct 16, 2018 at 9:32 AM
Subject: [ovirt-users] FOSDEM‘19 Virtualization & IaaS Devroom CfP
To: users 
Cc: Doron Fediuck 


We are excited to announce that the

call for proposals is now open for the Virtualization & IaaS devroom at the

upcoming FOSDEM 2019, to be hosted on February 2nd 2019.

This year will mark FOSDEM’s 19th anniversary as one of the longest-running

free and open source software developer events, attracting thousands of

developers and users from all over the world. FOSDEM will be held once

again in Brussels, Belgium, on February 2nd & 3rd, 2019.

This devroom is a collaborative effort, and is organized by dedicated folks

from projects such as OpenStack, Xen Project, oVirt, QEMU, KVM, and

Foreman. We would like to invite all those who are involved in these fields

to submit your proposals by December 1st, 2018.

About the Devroom

The Virtualization & IaaS devroom will feature session topics such as open

source hypervisors and virtual machine managers such as Xen Project, KVM,

bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as
KubeVirt,

Apache CloudStack, OpenStack, oVirt, QEMU and OpenNebula.

This devroom will host presentations that focus on topics of shared

interest, such as KVM; libvirt; shared storage; virtualized networking;

cloud security; clustering and high availability; interfacing with multiple

hypervisors; hyperconverged deployments; and scaling across hundreds or

thousands of servers.

Presentations in this devroom will be aimed at developers working on these

platforms who are looking to collaborate and improve shared infrastructure

or solve common problems. We seek topics that encourage dialog between

projects and continued work post-FOSDEM.

Important Dates

Submission deadline: 1 December 2019

Acceptance notifications: 14 December 2019

Final schedule announcement: 21 December 2019

Devroom: 2nd February 2019

Submit Your Proposal

All submissions must be made via the Pentabarf event planning site[1]. If

you have not used Pentabarf before, you will need to create an account. If

you submitted proposals for FOSDEM in previous years, you can use your

existing account.

After creating the account, select Create Event to start the submission

process. Make sure to select Virtualization and IaaS devroom from the Track

list. Please fill out all the required fields, and provide a meaningful

abstract and description of your proposed session.

Submission Guidelines

We expect more proposals than we can possibly accept, so it is vitally

important that you submit your proposal on or before the deadline. Late

submissions are unlikely to be considered.

All presentation slots are 30 minutes, with 20 minutes planned for

presentations, and 10 minutes for Q

All presentations will be recorded and made available under Creative

Commons licenses. In the Submission notes field, please indicate that you

agree that your presentation will be licensed under the CC-By-SA-4.0 or

CC-By-4.0 license and that you agree to have your presentation recorded.

For example:

"If my presentation is accepted for FOSDEM, I hereby agree to license all

recordings, slides, and other associated materials under the Creative

Commons Attribution Share-Alike 4.0 International License. Sincerely,

."

In the Submission notes field, please also confirm that if your talk is

accepted, you will be able to attend FOSDEM and deliver your presentation.

We will not consider proposals from prospective speakers who are unsure

whether they will be able to secure funds for travel and lodging to attend

FOSDEM. (Sadly, we are not able to offer travel funding for prospective

speakers.)

Speaker Mentoring Program

As a part of the rising efforts to grow our communities and encourage a

diverse and inclusive conference ecosystem, we're happy to announce that

we'll be offering mentoring for new speakers. Our mentors can help you with

tasks such as reviewing your abstract, reviewing your presentation outline

or slides, or practicing your talk with you.

You may apply to the mentoring program as a newcomer speaker if you:

Never presented before or

Presented only lightning talks or

Presented full-length talks at small meetups (<50 ppl)

Submission Guidelines

Mentored presentations will have 25-minute slots, where 20 minutes will

include the presentation and 5 minutes will be reserved for questions.

The number of newcomer session slots is limited, so we will probably not be

able to accept all applications.

You must submit your talk and abstract to apply for the mentoring program,

our mentors are volunteering their time and will happily provide feedback

but won't write your presentation for you!

If you are experiencing problems

[ovirt-devel] Re: vdsm-client: Adding a new verb to vdsm

[Piotr Kliczewski]

On Thu, Nov 22, 2018 at 4:05 PM Nir Soffer  wrote:

> On Thu, Nov 22, 2018 at 2:06 PM Kaustav Majumder 
> wrote:
>
>> Hi all,
>> I was working on adding a new verb to vdsm-gluster [1]. But right now the
>> only way i see to test this is by using vdsm-client.I have patched a host
>> running vdsm with my code, but the vdsm-client is not showing the required
>> verb. Is there anything else needed to be done?
>>
>> Eg-vdsm-client --gluster-enabled GlusterVolume  globalOptionsList
>> [1] https://gerrit.ovirt.org/#/c/95636/
>>
>
> The yaml looks mostly OK, so I would expect the verb to be found.
>
> You probably need to created rpms and install this vdsm to make
> the new schema available, and then you can test it like this:
>
> vdsm-client --gluster-enabled Namespace -h
>

RPM would be the simplest. During creation there is pickle file created [1]
which is used by the client.

[1]
https://github.com/oVirt/vdsm/blob/master/lib/vdsm/api/schema_to_pickle.py


>
> (I'm not sure about --gluster-enabled, never used it)
>
> 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/WEFD4W4VC5DMZNHIABI5MNWWYHV72E4R/

[ovirt-devel] Re: amount of reports by abrt

[Piotr Kliczewski]

niedz., 11 lis 2018, 15:26: Nir Soffer  napisał(a):

> On Sat, Nov 10, 2018 at 8:19 PM Piotr Kliczewski <
> piotr.kliczew...@gmail.com> wrote:
>
>> I attended a talk about abrt and noticed there are good number of reports
>> [1] generated by issues in ovirt.
>>
>
> Interesting, but does not seem very useful now.
>
> For example this issue:
> https://retrace.fedoraproject.org/faf/reports/1800689/
>
> https://retrace.fedoraproject.org/faf/problems/bthash/?bth=78aadb337727a80e425738f897ce652408ee396d=f9f894ff896f63455df6175635c7ec441cab225
>
> 11103922 reports for ovirt-imageio-daemon 1.0.0
> 6501 repots for ovirt-imageio-daemon 1.1.0
>
> But there is no info about this error, except the name of the exception
> NoSectionError
> Which means code tried to access non-existing section in a config file.
>
> The current version of imageio is 1.4.5, and the version released with
> 4.2.0 was 1.3 or 1.4, so this whatever this issue was, it is not relevant
> for long time.
>
> This could be more relevant if we could get mail about reports when they
> are submitted to the system. Do you know how we can configure the
> system to make the reports more useful?
>

Not sure but will ask about email notifications and if there is a way to
remove old, not vaild reports.


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

[ovirt-devel] Re: amount of reports by abrt

[Piotr Kliczewski]

niedz., 11 lis 2018, 09:16: Dan Kenigsberg  napisał(a):

> On Sat, Nov 10, 2018 at 8:19 PM Piotr Kliczewski
>  wrote:
> >
> > I attended a talk about abrt and noticed there are good number of
> reports [1] generated by issues in ovirt.
>
>
> Did they teach how to read these reports?
> Can you tell what is the 10 most common exceptions occurring in oVirt
> context?
>

Yes, please take a look at [1]. There are good numbers of reports for ovirt
components some with many millions occurrances over several years.


> >
> > Thanks,
> > Piotr
> >
> > [1] https://retrace.fedoraproject.org/faf/reports/
> > ___
> > 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/EECX2SVR4Q4TG4BWZWZCTKIC335ZH6CH/
>
___
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/BZAPTSER5UJVEVCI2LAP5VCADFCEGDXG/

[ovirt-devel] amount of reports by abrt

[Piotr Kliczewski]

I attended a talk about abrt and noticed there are good number of reports
[1] generated by issues in ovirt.

Thanks,
Piotr

[1] https://retrace.fedoraproject.org/faf/reports/
___
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/EECX2SVR4Q4TG4BWZWZCTKIC335ZH6CH/

[ovirt-devel] Re: [VDSM] test_echo(1024, False) (stomp_test.StompTests) fails

[Piotr Kliczewski]

On Wed, Nov 7, 2018 at 1:16 PM Nir Soffer  wrote:

> On Wed, Nov 7, 2018 at 10:13 AM Piotr Kliczewski 
> wrote:
>
>>
>>
>> On Wed, Nov 7, 2018 at 5:21 AM Germano Veit Michel 
>> wrote:
>>
>>>
>>> On Sat, Jun 30, 2018 at 12:43 AM Piotr Kliczewski <
>>> piotr.kliczew...@gmail.com> wrote:
>>>
>>>> Here is the patch [1] which should fix it.
>>>>
>>>> [1] https://gerrit.ovirt.org/#/c/92690/
>>>> On Thu, Jun 28, 2018 at 2:44 PM Piotr Kliczewski 
>>>> wrote:
>>>> >
>>>> > Nir,
>>>> >
>>>> > It looks like we have a race condition where request arrive sooner
>>>> than subscribe frame:
>>>> >
>>>> > 16:19:02 2018-06-27 14:17:54,653 INFO  (jsonrpc/0)
>>>> [jsonrpc.JsonRpcServer] RPC call echo succeeded in 0.01 seconds
>>>> (__init__:311)
>>>> > 16:19:02 2018-06-27 14:17:54,661 INFO  (Detector thread)
>>>> [Broker.StompAdapter] Subscribe command received (stompserver:123)
>>>> >
>>>> > Thanks for reporting I will push a patch to fix it.
>>>> >
>>>> > Thanks,
>>>> > Piotr
>>>> >
>>>> >
>>>> > On Wed, Jun 27, 2018 at 5:40 PM, Piotr Kliczewski <
>>>> pklic...@redhat.com> wrote:
>>>> >>
>>>> >> Ok, I'll take a look.
>>>> >>
>>>> >> śr., 27 cze 2018, 17:36 użytkownik Nir Soffer 
>>>> napisał:
>>>> >>>
>>>> >>> On Wed, Jun 27, 2018 at 6:13 PM Piotr Kliczewski <
>>>> pklic...@redhat.com> wrote:
>>>> >>>>
>>>> >>>> On Wed, Jun 27, 2018 at 5:01 PM, Nir Soffer 
>>>> wrote:
>>>> >>>>>
>>>> >>>>> This tests used to fail in the past, but since we fixed it or the
>>>> code
>>>> >>>>>
>>>> >>>>> it never failed.
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> Maybe the slave was overloaded?
>>>> >>>>
>>>> >>>>
>>>> >>>> Very possible. Can you paste a link to the job which failed?
>>>> >>>
>>>> >>>
>>>> >>> Here:
>>>> https://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/24130/
>>>> >>>
>>>> >>> The next build passed.
>>>> >>>
>>>> >>> Maybe we need to solve the flakiness of some tests by running a
>>>> flaky test
>>>> >>> again, and let the build fail only if a test failed twice. I wonder
>>>> if there is some
>>>> >>> pytest plugin doing this.
>>>> >>>
>>>> >>>>
>>>> >>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> 14:19:02
>>>> ==
>>>> >>>>> 14:19:02 ERROR:
>>>> >>>>>
>>>> >>>>> 14:19:02
>>>> --
>>>> >>>>> 14:19:02 Traceback (most recent call last):
>>>> >>>>> 14:19:02   File
>>>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/testlib.py",
>>>> line 143, in wrapper
>>>> >>>>> 14:19:02 return f(self, *args)
>>>> >>>>> 14:19:02   File
>>>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/stomp_test.py",
>>>> line 95, in test_echo
>>>> >>>>> 14:19:02 str(uuid4())),
>>>> >>>>> 14:19:02   File
>>>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/lib/yajsonrpc/jsonrpcclient.py",
>>>> line 77, in callMethod
>>>> >>>>> 14:19:02 raise
>>>> exception.JsonRpcNoResponseError(method=methodName)
>>>> >>>>> 14:19:02 JsonRpcNoResponseError: No response for JSON-RPC
>>>> request: {'method': 'echo'}
>>>> >>>>> 14:19:02  >> begin captured logging <<
>>>> 
>>&

[ovirt-devel] Re: [VDSM] test_echo(1024, False) (stomp_test.StompTests) fails

[Piotr Kliczewski]

On Wed, Nov 7, 2018 at 5:21 AM Germano Veit Michel 
wrote:

>
> On Sat, Jun 30, 2018 at 12:43 AM Piotr Kliczewski <
> piotr.kliczew...@gmail.com> wrote:
>
>> Here is the patch [1] which should fix it.
>>
>> [1] https://gerrit.ovirt.org/#/c/92690/
>> On Thu, Jun 28, 2018 at 2:44 PM Piotr Kliczewski 
>> wrote:
>> >
>> > Nir,
>> >
>> > It looks like we have a race condition where request arrive sooner than
>> subscribe frame:
>> >
>> > 16:19:02 2018-06-27 14:17:54,653 INFO  (jsonrpc/0)
>> [jsonrpc.JsonRpcServer] RPC call echo succeeded in 0.01 seconds
>> (__init__:311)
>> > 16:19:02 2018-06-27 14:17:54,661 INFO  (Detector thread)
>> [Broker.StompAdapter] Subscribe command received (stompserver:123)
>> >
>> > Thanks for reporting I will push a patch to fix it.
>> >
>> > Thanks,
>> > Piotr
>> >
>> >
>> > On Wed, Jun 27, 2018 at 5:40 PM, Piotr Kliczewski 
>> wrote:
>> >>
>> >> Ok, I'll take a look.
>> >>
>> >> śr., 27 cze 2018, 17:36 użytkownik Nir Soffer 
>> napisał:
>> >>>
>> >>> On Wed, Jun 27, 2018 at 6:13 PM Piotr Kliczewski 
>> wrote:
>> >>>>
>> >>>> On Wed, Jun 27, 2018 at 5:01 PM, Nir Soffer 
>> wrote:
>> >>>>>
>> >>>>> This tests used to fail in the past, but since we fixed it or the
>> code
>> >>>>>
>> >>>>> it never failed.
>> >>>>>
>> >>>>>
>> >>>>> Maybe the slave was overloaded?
>> >>>>
>> >>>>
>> >>>> Very possible. Can you paste a link to the job which failed?
>> >>>
>> >>>
>> >>> Here:
>> https://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/24130/
>> >>>
>> >>> The next build passed.
>> >>>
>> >>> Maybe we need to solve the flakiness of some tests by running a flaky
>> test
>> >>> again, and let the build fail only if a test failed twice. I wonder
>> if there is some
>> >>> pytest plugin doing this.
>> >>>
>> >>>>
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> 14:19:02
>> ==
>> >>>>> 14:19:02 ERROR:
>> >>>>>
>> >>>>> 14:19:02
>> --
>> >>>>> 14:19:02 Traceback (most recent call last):
>> >>>>> 14:19:02   File
>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/testlib.py",
>> line 143, in wrapper
>> >>>>> 14:19:02 return f(self, *args)
>> >>>>> 14:19:02   File
>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/stomp_test.py",
>> line 95, in test_echo
>> >>>>> 14:19:02 str(uuid4())),
>> >>>>> 14:19:02   File
>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/lib/yajsonrpc/jsonrpcclient.py",
>> line 77, in callMethod
>> >>>>> 14:19:02 raise
>> exception.JsonRpcNoResponseError(method=methodName)
>> >>>>> 14:19:02 JsonRpcNoResponseError: No response for JSON-RPC request:
>> {'method': 'echo'}
>> >>>>> 14:19:02  >> begin captured logging <<
>> 
>> >>>>> 14:19:02 2018-06-27 14:17:54,524 DEBUG (MainThread)
>> [vds.MultiProtocolAcceptor] Creating socket (host='::1', port=0, family=10,
>> socketype=1, proto=6) (protocoldetector:225)
>> >>>>> 14:19:02 2018-06-27 14:17:54,526 INFO  (MainThread)
>> [vds.MultiProtocolAcceptor] Listening at ::1:36713 (protocoldetector:183)
>> >>>>> 14:19:02 2018-06-27 14:17:54,535 DEBUG (MainThread) [Scheduler]
>> Starting scheduler test.Scheduler (schedule:98)
>> >>>>> 14:19:02 2018-06-27 14:17:54,537 DEBUG (test.Scheduler) [Scheduler]
>> START thread 
>> (func=> 0x7fd74ca00390>>, args=(), kwargs={}) (concurrent:193)
>> >>>>> 14:19:02 2018-06-27 14:17:54,538 DEBUG (test.Scheduler) [Scheduler]
>> started (schedule:140)
>> >>>>> 14:19:02 2018-06-27 14:17:54,546 DEBUG (JsonRpc (StompReactor))
>&

[ovirt-devel] Re: Decipher traffic between ovirt-engine and ovirt-node (vdsm)

[Piotr Kliczewski]

On Sat, Oct 27, 2018 at 6:14 AM Anastasiya Ruzhanskaya <
anastasiya.ruzhansk...@frtk.ru> wrote:

> I just need to make an overlay on this system as in our organization it
> will be more problematic to certify the whole ovirt than our tool for calls
> filtering. Just the organizational reason. Also we want to use an attribute
> based model.
>

I still fail to understand why do you need network level filtering.
Structure of your organization should be model using permissions. Which
calls/functionality is problematic?


>
> чт, 25 окт. 2018 г. в 23:02, Piotr Kliczewski :
>
>>
>>
>> On Thu, Oct 25, 2018 at 10:10 AM Anastasiya Ruzhanskaya <
>> anastasiya.ruzhansk...@frtk.ru> wrote:
>>
>>> Ok, I understood. Thank you for the information. And could you please
>>> somehow comment the approach with error sending which I described in a
>>> previous email?
>>>
>>
>> I am not sure what would be correct error to return here since every
>> error has a meaning for engine. For some we fail the action but for others
>> we attempt to retry fix, fix the issue by
>> soft fencing the host.
>>
>> Can you share with me what are you missing from current authorization
>> model so you need to filter the calls?
>>
>>
>>>
>>> четверг, 25 октября 2018 г. пользователь Piotr Kliczewski написал:
>>>
>>>>
>>>>
>>>> czw., 25 paź 2018, 06:32 użytkownik Anastasiya Ruzhanskaya <
>>>> anastasiya.ruzhansk...@frtk.ru> napisał:
>>>>
>>>>> Also in official docs of oVirt it is written that xml rpc is used. For
>>>>> example here :
>>>>> https://ovirt.org/documentation/architecture/architecture/
>>>>> So, this is an incorrect info, right?
>>>>>
>>>>
>>>> This doc seems not to up to date for quite some time. Now we use
>>>> jsonrpc over stomp.
>>>>
>>>>
>>>>> чт, 25 окт. 2018 г. в 7:28, Anastasiya Ruzhanskaya <
>>>>> anastasiya.ruzhansk...@frtk.ru>:
>>>>>
>>>>>> In virt-manager for the same purpose there was an option to send
>>>>>> error messages with help of mitmproxy. I modified  a little bit this 
>>>>>> proxy
>>>>>> to be able to use it with any tcp connection.
>>>>>> And this error message was correctly processed. But the amount of
>>>>>> source code for analysis in that case was rather small and I found rather
>>>>>> quickly how error messages should be sent and encoded in rpc.
>>>>>>
>>>>>> Is there any possibility like this here?
>>>>>>
>>>>>> чт, 25 окт. 2018 г. в 0:47, Piotr Kliczewski :
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Oct 24, 2018 at 9:34 PM Anastasiya Ruzhanskaya <
>>>>>>> anastasiya.ruzhansk...@frtk.ru> wrote:
>>>>>>>
>>>>>>>> My proxy is based on mitmproxy, so I want to analyze messages
>>>>>>>> coming from client to ovirt-engine or from engine to node and based on 
>>>>>>>> the
>>>>>>>> content permit the actions or not. I know that there is access control
>>>>>>>> inside oVirt, but I need to implement the similar thing by myself using
>>>>>>>> proxy. From ovirt-engine to vdsm it is trickier as there I have no 
>>>>>>>> users
>>>>>>>> and session ids to identify the actor, I can determine only actions.
>>>>>>>>
>>>>>>>
>>>>>>> By using engine or vdsm certs you could decrypt the traffic. How
>>>>>>> would you prevent command from being executed. If you drop packet(s) the
>>>>>>> engine would attempt to retry or consider vdsm to be down/dead. In 
>>>>>>> either
>>>>>>> case engine would be confused.
>>>>>>> I would not recommend such approach because it may prevent you from
>>>>>>> using oVirt or break it.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> But anyway, I can decipher normal rpc ( for virt-manager), got
>>>>>>>> familiar with gwt -rpc ( client-engine) and now trying to understand 
>>>>>>>> what
>>>>>>>> is happening with xml 

[ovirt-devel] Re: Decipher traffic between ovirt-engine and ovirt-node (vdsm)

[Piotr Kliczewski]

On Thu, Oct 25, 2018 at 10:10 AM Anastasiya Ruzhanskaya <
anastasiya.ruzhansk...@frtk.ru> wrote:

> Ok, I understood. Thank you for the information. And could you please
> somehow comment the approach with error sending which I described in a
> previous email?
>

I am not sure what would be correct error to return here since every error
has a meaning for engine. For some we fail the action but for others we
attempt to retry fix, fix the issue by
soft fencing the host.

Can you share with me what are you missing from current authorization model
so you need to filter the calls?


>
> четверг, 25 октября 2018 г. пользователь Piotr Kliczewski написал:
>
>>
>>
>> czw., 25 paź 2018, 06:32 użytkownik Anastasiya Ruzhanskaya <
>> anastasiya.ruzhansk...@frtk.ru> napisał:
>>
>>> Also in official docs of oVirt it is written that xml rpc is used. For
>>> example here :
>>> https://ovirt.org/documentation/architecture/architecture/
>>> So, this is an incorrect info, right?
>>>
>>
>> This doc seems not to up to date for quite some time. Now we use jsonrpc
>> over stomp.
>>
>>
>>> чт, 25 окт. 2018 г. в 7:28, Anastasiya Ruzhanskaya <
>>> anastasiya.ruzhansk...@frtk.ru>:
>>>
>>>> In virt-manager for the same purpose there was an option to send error
>>>> messages with help of mitmproxy. I modified  a little bit this proxy to be
>>>> able to use it with any tcp connection.
>>>> And this error message was correctly processed. But the amount of
>>>> source code for analysis in that case was rather small and I found rather
>>>> quickly how error messages should be sent and encoded in rpc.
>>>>
>>>> Is there any possibility like this here?
>>>>
>>>> чт, 25 окт. 2018 г. в 0:47, Piotr Kliczewski :
>>>>
>>>>>
>>>>>
>>>>> On Wed, Oct 24, 2018 at 9:34 PM Anastasiya Ruzhanskaya <
>>>>> anastasiya.ruzhansk...@frtk.ru> wrote:
>>>>>
>>>>>> My proxy is based on mitmproxy, so I want to analyze messages coming
>>>>>> from client to ovirt-engine or from engine to node and based on the 
>>>>>> content
>>>>>> permit the actions or not. I know that there is access control inside
>>>>>> oVirt, but I need to implement the similar thing by myself using proxy.
>>>>>> From ovirt-engine to vdsm it is trickier as there I have no users and
>>>>>> session ids to identify the actor, I can determine only actions.
>>>>>>
>>>>>
>>>>> By using engine or vdsm certs you could decrypt the traffic. How would
>>>>> you prevent command from being executed. If you drop packet(s) the engine
>>>>> would attempt to retry or consider vdsm to be down/dead. In either case
>>>>> engine would be confused.
>>>>> I would not recommend such approach because it may prevent you from
>>>>> using oVirt or break it.
>>>>>
>>>>>
>>>>>>
>>>>>> But anyway, I can decipher normal rpc ( for virt-manager), got
>>>>>> familiar with gwt -rpc ( client-engine) and now trying to understand what
>>>>>> is happening with xml rpc.
>>>>>>
>>>>>
>>>>> As Nir mentioned we estabilish tcp connection and send jsonrpc over
>>>>> stomp.
>>>>>
>>>>>
>>>>>>
>>>>>> ср, 24 окт. 2018 г. в 21:41, Nir Soffer :
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, 24 Oct 2018, 18:51 Anastasiya Ruzhanskaya, <
>>>>>>> anastasiya.ruzhansk...@frtk.ru> wrote:
>>>>>>>
>>>>>>>> I need this for my proxy,
>>>>>>>>
>>>>>>>
>>>>>>> What is your proxy?
>>>>>>>
>>>>>>> I need to do this analysis "online", not just by analyzing the logs
>>>>>>>> after the action happened.
>>>>>>>>
>>>>>>>> ср, 24 окт. 2018 г. в 19:00, Nir Soffer :
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, 24 Oct 2018, 13:16 Anastasiya Ruzhanskaya, <
>>>>>>>>> anastasiya.ruzhansk...@frtk.ru> wrote:
>>>>>>>>>
>>>>>>>>>> Hell

[ovirt-devel] Re: Decipher traffic between ovirt-engine and ovirt-node (vdsm)

[Piotr Kliczewski]

czw., 25 paź 2018, 06:32 użytkownik Anastasiya Ruzhanskaya <
anastasiya.ruzhansk...@frtk.ru> napisał:

> Also in official docs of oVirt it is written that xml rpc is used. For
> example here : https://ovirt.org/documentation/architecture/architecture/
> So, this is an incorrect info, right?
>

This doc seems not to up to date for quite some time. Now we use jsonrpc
over stomp.


> чт, 25 окт. 2018 г. в 7:28, Anastasiya Ruzhanskaya <
> anastasiya.ruzhansk...@frtk.ru>:
>
>> In virt-manager for the same purpose there was an option to send error
>> messages with help of mitmproxy. I modified  a little bit this proxy to be
>> able to use it with any tcp connection.
>> And this error message was correctly processed. But the amount of source
>> code for analysis in that case was rather small and I found rather quickly
>> how error messages should be sent and encoded in rpc.
>>
>> Is there any possibility like this here?
>>
>> чт, 25 окт. 2018 г. в 0:47, Piotr Kliczewski :
>>
>>>
>>>
>>> On Wed, Oct 24, 2018 at 9:34 PM Anastasiya Ruzhanskaya <
>>> anastasiya.ruzhansk...@frtk.ru> wrote:
>>>
>>>> My proxy is based on mitmproxy, so I want to analyze messages coming
>>>> from client to ovirt-engine or from engine to node and based on the content
>>>> permit the actions or not. I know that there is access control inside
>>>> oVirt, but I need to implement the similar thing by myself using proxy.
>>>> From ovirt-engine to vdsm it is trickier as there I have no users and
>>>> session ids to identify the actor, I can determine only actions.
>>>>
>>>
>>> By using engine or vdsm certs you could decrypt the traffic. How would
>>> you prevent command from being executed. If you drop packet(s) the engine
>>> would attempt to retry or consider vdsm to be down/dead. In either case
>>> engine would be confused.
>>> I would not recommend such approach because it may prevent you from
>>> using oVirt or break it.
>>>
>>>
>>>>
>>>> But anyway, I can decipher normal rpc ( for virt-manager), got familiar
>>>> with gwt -rpc ( client-engine) and now trying to understand what is
>>>> happening with xml rpc.
>>>>
>>>
>>> As Nir mentioned we estabilish tcp connection and send jsonrpc over
>>> stomp.
>>>
>>>
>>>>
>>>> ср, 24 окт. 2018 г. в 21:41, Nir Soffer :
>>>>
>>>>>
>>>>>
>>>>> On Wed, 24 Oct 2018, 18:51 Anastasiya Ruzhanskaya, <
>>>>> anastasiya.ruzhansk...@frtk.ru> wrote:
>>>>>
>>>>>> I need this for my proxy,
>>>>>>
>>>>>
>>>>> What is your proxy?
>>>>>
>>>>> I need to do this analysis "online", not just by analyzing the logs
>>>>>> after the action happened.
>>>>>>
>>>>>> ср, 24 окт. 2018 г. в 19:00, Nir Soffer :
>>>>>>
>>>>>>>
>>>>>>> On Wed, 24 Oct 2018, 13:16 Anastasiya Ruzhanskaya, <
>>>>>>> anastasiya.ruzhansk...@frtk.ru> wrote:
>>>>>>>
>>>>>>>> Hello!
>>>>>>>> I was successful in deciphering the traffic between the client and
>>>>>>>> ovirt-engine,
>>>>>>>>
>>>>>>>
>>>>>>> Why do you need to do this? it is easier to add logging to vdsm of
>>>>>>> you want to see more info about the messages.
>>>>>>>
>>>>>>> Anyway Piotr may help.
>>>>>>>
>>>>>>> Nir
>>>>>>>
>>>>>>> actually, only by dumping the premaster key from the browser, which
>>>>>>>> was generated during the session and providing it to wireshark.
>>>>>>>>
>>>>>>>> How it can be done for ovirt-engine and vdsm communication? Should
>>>>>>>> the engine private key be provided? Actually to my surprise I don't 
>>>>>>>> see any
>>>>>>>> ssl communication between engine and node when for example turn on the
>>>>>>>> virtual machine, only tcp packets. But this page
>>>>>>>> https://ovirt.org/develop/release-management/features/infra/pki/
>>>>>>>> states that there should be one. And also should I look for any xml rpc
>>>>>>>> dissector? I know that for example virt-manager uses rpc protocol, I 
>>>>>>>> found
>>>>>>>> a dissector for that case, but seems I need another one here.
>>>>>>>> ___
>>>>>>>> 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/HJOBKO5MOF56NFEXX6Z2T7RBTFX6OACP/
>>>>>>>>
>>>>>>>
___
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/GNIMBRY7UM27JXC5JIWLBGNA2GXM76Z7/

[ovirt-devel] Re: Decipher traffic between ovirt-engine and ovirt-node (vdsm)

[Piotr Kliczewski]

On Wed, Oct 24, 2018 at 9:34 PM Anastasiya Ruzhanskaya <
anastasiya.ruzhansk...@frtk.ru> wrote:

> My proxy is based on mitmproxy, so I want to analyze messages coming from
> client to ovirt-engine or from engine to node and based on the content
> permit the actions or not. I know that there is access control inside
> oVirt, but I need to implement the similar thing by myself using proxy.
> From ovirt-engine to vdsm it is trickier as there I have no users and
> session ids to identify the actor, I can determine only actions.
>

By using engine or vdsm certs you could decrypt the traffic. How would you
prevent command from being executed. If you drop packet(s) the engine would
attempt to retry or consider vdsm to be down/dead. In either case engine
would be confused.
I would not recommend such approach because it may prevent you from using
oVirt or break it.


>
> But anyway, I can decipher normal rpc ( for virt-manager), got familiar
> with gwt -rpc ( client-engine) and now trying to understand what is
> happening with xml rpc.
>

As Nir mentioned we estabilish tcp connection and send jsonrpc over stomp.


>
> ср, 24 окт. 2018 г. в 21:41, Nir Soffer :
>
>>
>>
>> On Wed, 24 Oct 2018, 18:51 Anastasiya Ruzhanskaya, <
>> anastasiya.ruzhansk...@frtk.ru> wrote:
>>
>>> I need this for my proxy,
>>>
>>
>> What is your proxy?
>>
>> I need to do this analysis "online", not just by analyzing the logs after
>>> the action happened.
>>>
>>> ср, 24 окт. 2018 г. в 19:00, Nir Soffer :
>>>

 On Wed, 24 Oct 2018, 13:16 Anastasiya Ruzhanskaya, <
 anastasiya.ruzhansk...@frtk.ru> wrote:

> Hello!
> I was successful in deciphering the traffic between the client and
> ovirt-engine,
>

 Why do you need to do this? it is easier to add logging to vdsm of you
 want to see more info about the messages.

 Anyway Piotr may help.

 Nir

 actually, only by dumping the premaster key from the browser, which was
> generated during the session and providing it to wireshark.
>
> How it can be done for ovirt-engine and vdsm communication? Should the
> engine private key be provided? Actually to my surprise I don't see any 
> ssl
> communication between engine and node when for example turn on the virtual
> machine, only tcp packets. But this page
> https://ovirt.org/develop/release-management/features/infra/pki/
> states that there should be one. And also should I look for any xml rpc
> dissector? I know that for example virt-manager uses rpc protocol, I found
> a dissector for that case, but seems I need another one here.
> ___
> 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/HJOBKO5MOF56NFEXX6Z2T7RBTFX6OACP/
>

___
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/37TCCGDKZV7AGEP2WIJ5LLM5WKXQ4HIJ/

[ovirt-devel] ovirt-engine has been tagged (ovirt-engine-4.2.7.2)

[Piotr Kliczewski]

___
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/IPIYY3LK5H5VIEWJSFALMW47G2UBMAM3/

[ovirt-devel] ovirt-engine has been tagged (ovirt-engine-4.2.7.1)

[Piotr Kliczewski]

___
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/5TB2EBDLRCVDKUJYV7EPLUFGDKNQ56U4/

[ovirt-devel] Re: Dealing with TaskID in vdsm api

[Piotr Kliczewski]

On Fri, Sep 21, 2018 at 3:45 AM, Germano Veit Michel 
wrote:

>
>
> On Thu, Sep 20, 2018 at 5:08 PM Piotr Kliczewski 
> wrote:
>
>>
>>
>> On Thu, Sep 20, 2018 at 12:55 AM, Germano Veit Michel > > wrote:
>>
>>>
>>>
>>> On Thu, Sep 20, 2018 at 7:14 AM Nir Soffer  wrote:
>>>
>>>>
>>>>
>>>> On Mon, 17 Sep 2018, 8:06 Germano Veit Michel, 
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I've been struggling with TaskID/FlowID when talking to the VDSM API.
>>>>> I am trying to write a tool that uses the vdsm-api to facilitate the
>>>>> troubleshooting of image issues (snapshots). This tool does a series of 
>>>>> API
>>>>> calls, but I cannot find a nice way to track the taskID and clear the
>>>>> completed tasks after completion of the tool commands. Currently I'm
>>>>> clearing all Tasks that match the verb and are finished, which is not
>>>>> ideal. I would like to have the exact TaskID to track and dont want to
>>>>> leave Tasks behind. I don't want also to clear tasks from other entities
>>>>> (like engine!).
>>>>>
>>>>
>>>> Storage jobs are managed using (client generated) job id. The task id
>>>> is internal
>>>> implementation detail which will likely disappear in future version.
>>>> You don'need
>>>> to monitor or clean the internal tasks, they are managed by the storage
>>>> jobs
>>>> framework for you.
>>>>
>>>
>>> Thanks for the clarification Nir!
>>>
>>>
>>>> You can check engine code to understand how storage jobs are managed.
>>>>
>>>>
>>>>> I understand that if I want to specify the task/flow ids when calling
>>>>> the vdsm API, these two need to be passed as headers (http) so they end up
>>>>> in the context of the call. Is this correct? But using vdsm/client.py I
>>>>> cannot figure out how to do this, but I understand it is possible.
>>>>>
>>>>
>>>> This is not possible now, but sounds like a good idea. Please file RFE
>>>> to add this,
>>>> or if you have the time you can try to add. Looks like the place you
>>>> can add it is
>>>> in lib/yajsonrpc/stompclient.py - ClientRpcTransportAdapter.send().
>>>>
>>>
>>> Nice, I'll take a look.
>>>
>>>
>>>>
>>>> Piotr, what do you think?
>>>>
>>>
>> I agree. In situations like this it would be great to be able to provide
>> flow_id. It is possible to provide it in java based client [1].
>> Please open an RFE and we will implement it for you.
>>
>
> Thanks! I can help testing it as soon as you submit a patch, will cherry
> pick it once you send.
> RFE: https://bugzilla.redhat.com/show_bug.cgi?id=1631587
>
>

Thank you!


>
>> [1] https://github.com/oVirt/vdsm-jsonrpc-java/blob/
>> d964c7ea4aa841972c66c737a7787db6e4a40fad/client/src/main/
>> java/org/ovirt/vdsm/jsonrpc/client/reactors/stomp/impl/Message.java#L73
>>
>>
>>>
>>>> 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/P6GH6VZVHWPB46TZDOJ53ZVWELVQB2RQ/

[ovirt-devel] Re: Dealing with TaskID in vdsm api

[Piotr Kliczewski]

On Thu, Sep 20, 2018 at 12:55 AM, Germano Veit Michel 
wrote:

>
>
> On Thu, Sep 20, 2018 at 7:14 AM Nir Soffer  wrote:
>
>>
>>
>> On Mon, 17 Sep 2018, 8:06 Germano Veit Michel, 
>> wrote:
>>
>>> Hello,
>>>
>>> I've been struggling with TaskID/FlowID when talking to the VDSM API. I
>>> am trying to write a tool that uses the vdsm-api to facilitate the
>>> troubleshooting of image issues (snapshots). This tool does a series of API
>>> calls, but I cannot find a nice way to track the taskID and clear the
>>> completed tasks after completion of the tool commands. Currently I'm
>>> clearing all Tasks that match the verb and are finished, which is not
>>> ideal. I would like to have the exact TaskID to track and dont want to
>>> leave Tasks behind. I don't want also to clear tasks from other entities
>>> (like engine!).
>>>
>>
>> Storage jobs are managed using (client generated) job id. The task id is
>> internal
>> implementation detail which will likely disappear in future version. You
>> don'need
>> to monitor or clean the internal tasks, they are managed by the storage
>> jobs
>> framework for you.
>>
>
> Thanks for the clarification Nir!
>
>
>> You can check engine code to understand how storage jobs are managed.
>>
>>
>>> I understand that if I want to specify the task/flow ids when calling
>>> the vdsm API, these two need to be passed as headers (http) so they end up
>>> in the context of the call. Is this correct? But using vdsm/client.py I
>>> cannot figure out how to do this, but I understand it is possible.
>>>
>>
>> This is not possible now, but sounds like a good idea. Please file RFE to
>> add this,
>> or if you have the time you can try to add. Looks like the place you can
>> add it is
>> in lib/yajsonrpc/stompclient.py - ClientRpcTransportAdapter.send().
>>
>
> Nice, I'll take a look.
>
>
>>
>> Piotr, what do you think?
>>
>
I agree. In situations like this it would be great to be able to provide
flow_id. It is possible to provide it in java based client [1].
Please open an RFE and we will implement it for you.

[1]
https://github.com/oVirt/vdsm-jsonrpc-java/blob/d964c7ea4aa841972c66c737a7787db6e4a40fad/client/src/main/java/org/ovirt/vdsm/jsonrpc/client/reactors/stomp/impl/Message.java#L73


>
>> 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/42F3B3UAEJ5A5MB3DDM3TBOATJGGRXNO/

[ovirt-devel] Re: [VDSM] test_echo(1024, False) (stomp_test.StompTests) fails

[Piotr Kliczewski]

Here is the patch [1] which should fix it.

[1] https://gerrit.ovirt.org/#/c/92690/
On Thu, Jun 28, 2018 at 2:44 PM Piotr Kliczewski  wrote:
>
> Nir,
>
> It looks like we have a race condition where request arrive sooner than 
> subscribe frame:
>
> 16:19:02 2018-06-27 14:17:54,653 INFO  (jsonrpc/0) [jsonrpc.JsonRpcServer] 
> RPC call echo succeeded in 0.01 seconds (__init__:311)
> 16:19:02 2018-06-27 14:17:54,661 INFO  (Detector thread) 
> [Broker.StompAdapter] Subscribe command received (stompserver:123)
>
> Thanks for reporting I will push a patch to fix it.
>
> Thanks,
> Piotr
>
>
> On Wed, Jun 27, 2018 at 5:40 PM, Piotr Kliczewski  wrote:
>>
>> Ok, I'll take a look.
>>
>> śr., 27 cze 2018, 17:36 użytkownik Nir Soffer  napisał:
>>>
>>> On Wed, Jun 27, 2018 at 6:13 PM Piotr Kliczewski  
>>> wrote:
>>>>
>>>> On Wed, Jun 27, 2018 at 5:01 PM, Nir Soffer  wrote:
>>>>>
>>>>> This tests used to fail in the past, but since we fixed it or the code
>>>>>
>>>>> it never failed.
>>>>>
>>>>>
>>>>> Maybe the slave was overloaded?
>>>>
>>>>
>>>> Very possible. Can you paste a link to the job which failed?
>>>
>>>
>>> Here: 
>>> https://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/24130/
>>>
>>> The next build passed.
>>>
>>> Maybe we need to solve the flakiness of some tests by running a flaky test
>>> again, and let the build fail only if a test failed twice. I wonder if 
>>> there is some
>>> pytest plugin doing this.
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> 14:19:02 
>>>>> ==
>>>>> 14:19:02 ERROR:
>>>>>
>>>>> 14:19:02 
>>>>> --
>>>>> 14:19:02 Traceback (most recent call last):
>>>>> 14:19:02   File 
>>>>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/testlib.py",
>>>>>  line 143, in wrapper
>>>>> 14:19:02 return f(self, *args)
>>>>> 14:19:02   File 
>>>>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/stomp_test.py",
>>>>>  line 95, in test_echo
>>>>> 14:19:02 str(uuid4())),
>>>>> 14:19:02   File 
>>>>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/lib/yajsonrpc/jsonrpcclient.py",
>>>>>  line 77, in callMethod
>>>>> 14:19:02 raise exception.JsonRpcNoResponseError(method=methodName)
>>>>> 14:19:02 JsonRpcNoResponseError: No response for JSON-RPC request: 
>>>>> {'method': 'echo'}
>>>>> 14:19:02  >> begin captured logging << 
>>>>> 
>>>>> 14:19:02 2018-06-27 14:17:54,524 DEBUG (MainThread) 
>>>>> [vds.MultiProtocolAcceptor] Creating socket (host='::1', port=0, 
>>>>> family=10, socketype=1, proto=6) (protocoldetector:225)
>>>>> 14:19:02 2018-06-27 14:17:54,526 INFO  (MainThread) 
>>>>> [vds.MultiProtocolAcceptor] Listening at ::1:36713 (protocoldetector:183)
>>>>> 14:19:02 2018-06-27 14:17:54,535 DEBUG (MainThread) [Scheduler] Starting 
>>>>> scheduler test.Scheduler (schedule:98)
>>>>> 14:19:02 2018-06-27 14:17:54,537 DEBUG (test.Scheduler) [Scheduler] START 
>>>>> thread  
>>>>> (func=>>>> 0x7fd74ca00390>>, args=(), kwargs={}) (concurrent:193)
>>>>> 14:19:02 2018-06-27 14:17:54,538 DEBUG (test.Scheduler) [Scheduler] 
>>>>> started (schedule:140)
>>>>> 14:19:02 2018-06-27 14:17:54,546 DEBUG (JsonRpc (StompReactor)) [root] 
>>>>> START thread >>>> 140562629256960)> (func=>>>> >, args=(), 
>>>>> kwargs={}) (concurrent:193)
>>>>> 14:19:02 2018-06-27 14:17:54,547 DEBUG (MainThread) [Executor] Starting 
>>>>> executor (executor:128)
>>>>> 14:19:02 2018-06-27 14:17:54,549 DEBUG (MainThread) [Executor] Starting 
>>>>> worker jsonrpc/0 (executor:286)
>>>>> 14:19:02 2018-06-27 14:17:54,553 DEBUG (jsonrpc/0) [Executor] START 
>>>>> thread  (func=>>>> method _Worker._run of >>>> 0x7fd74ca

[ovirt-devel] Re: [VDSM] test_echo(1024, False) (stomp_test.StompTests) fails

[Piotr Kliczewski]

Nir,

It looks like we have a race condition where request arrive sooner than
subscribe frame:

*16:19:02* 2018-06-27 14:17:54,653 INFO  (jsonrpc/0)
[jsonrpc.JsonRpcServer] RPC call echo succeeded in 0.01 seconds
(__init__:311)*16:19:02* 2018-06-27 14:17:54,661 INFO  (Detector
thread) [Broker.StompAdapter] Subscribe command received
(stompserver:123)

Thanks for reporting I will push a patch to fix it.

Thanks,
Piotr


On Wed, Jun 27, 2018 at 5:40 PM, Piotr Kliczewski 
wrote:

> Ok, I'll take a look.
>
> śr., 27 cze 2018, 17:36 użytkownik Nir Soffer 
> napisał:
>
>> On Wed, Jun 27, 2018 at 6:13 PM Piotr Kliczewski 
>> wrote:
>>
>>> On Wed, Jun 27, 2018 at 5:01 PM, Nir Soffer  wrote:
>>>
>>>> This tests used to fail in the past, but since we fixed it or the code
>>>>
>>>> it never failed.
>>>>
>>>>
>>>> Maybe the slave was overloaded?
>>>>
>>>>
>>> Very possible. Can you paste a link to the job which failed?
>>>
>>
>> Here: https://jenkins.ovirt.org/job/vdsm_master_check-
>> patch-el7-x86_64/24130/
>>
>> The next build passed.
>>
>> Maybe we need to solve the flakiness of some tests by running a flaky test
>> again, and let the build fail only if a test failed twice. I wonder if
>> there is some
>> pytest plugin doing this.
>>
>>
>>>
>>>
>>>>
>>>> *14:19:02* 
>>>> ==*14:19:02*
>>>>  ERROR:
>>>>
>>>> *14:19:02* 
>>>> --*14:19:02*
>>>>  Traceback (most recent call last):*14:19:02*   File 
>>>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/testlib.py",
>>>>  line 143, in wrapper*14:19:02* return f(self, *args)*14:19:02*   File 
>>>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/stomp_test.py",
>>>>  line 95, in test_echo*14:19:02* str(uuid4())),*14:19:02*   File 
>>>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/lib/yajsonrpc/jsonrpcclient.py",
>>>>  line 77, in callMethod*14:19:02* raise 
>>>> exception.JsonRpcNoResponseError(method=methodName)*14:19:02* 
>>>> JsonRpcNoResponseError: No response for JSON-RPC request: {'method': 
>>>> 'echo'}*14:19:02*  >> begin captured logging << 
>>>> *14:19:02* 2018-06-27 14:17:54,524 DEBUG (MainThread) 
>>>> [vds.MultiProtocolAcceptor] Creating socket (host='::1', port=0, 
>>>> family=10, socketype=1, proto=6) (protocoldetector:225)*14:19:02* 
>>>> 2018-06-27 14:17:54,526 INFO  (MainThread) [vds.MultiProtocolAcceptor] 
>>>> Listening at ::1:36713 (protocoldetector:183)*14:19:02* 2018-06-27 
>>>> 14:17:54,535 DEBUG (MainThread) [Scheduler] Starting scheduler 
>>>> test.Scheduler (schedule:98)*14:19:02* 2018-06-27 14:17:54,537 DEBUG 
>>>> (test.Scheduler) [Scheduler] START thread >>> daemon 140562082535168)> (func=>>> >, args=(), kwargs={}) 
>>>> (concurrent:193)*14:19:02* 2018-06-27 14:17:54,538 DEBUG (test.Scheduler) 
>>>> [Scheduler] started (schedule:140)*14:19:02* 2018-06-27 14:17:54,546 DEBUG 
>>>> (JsonRpc (StompReactor)) [root] START thread >>> (StompReactor), started daemon 140562629256960)> (func=>>> StompReactor.process_requests of >>> object at 0x7fd74ca006d0>>, args=(), kwargs={}) (concurrent:193)*14:19:02* 
>>>> 2018-06-27 14:17:54,547 DEBUG (MainThread) [Executor] Starting executor 
>>>> (executor:128)*14:19:02* 2018-06-27 14:17:54,549 DEBUG (MainThread) 
>>>> [Executor] Starting worker jsonrpc/0 (executor:286)*14:19:02* 2018-06-27 
>>>> 14:17:54,553 DEBUG (jsonrpc/0) [Executor] START thread >>> started daemon 140562612471552)> (func=>>> >, args=(), 
>>>> kwargs={}) (concurrent:193)*14:19:02* 2018-06-27 14:17:54,554 DEBUG 
>>>> (jsonrpc/0) [Executor] Worker started (executor:298)*14:19:02* 2018-06-27 
>>>> 14:17:54,557 DEBUG (MainThread) [Executor] Starting worker jsonrpc/1 
>>>> (executor:286)*14:19:02* 2018-06-27 14:17:54,558 DEBUG (MainThread) 
>>>> [Executor] Starting worker jsonrpc/2 (executor:286)*14:19:02* 2018-06-27 
>>>> 14:17:54,559 DEBUG (jsonrpc/2) [Executor] START thread >>> started daemon 140562620864256)> (func=>>> >, args=(), 
>>>>

[ovirt-devel] Re: [VDSM] test_echo(1024, False) (stomp_test.StompTests) fails

[Piotr Kliczewski]

Ok, I'll take a look.

śr., 27 cze 2018, 17:36 użytkownik Nir Soffer  napisał:

> On Wed, Jun 27, 2018 at 6:13 PM Piotr Kliczewski 
> wrote:
>
>> On Wed, Jun 27, 2018 at 5:01 PM, Nir Soffer  wrote:
>>
>>> This tests used to fail in the past, but since we fixed it or the code
>>>
>>> it never failed.
>>>
>>>
>>> Maybe the slave was overloaded?
>>>
>>>
>> Very possible. Can you paste a link to the job which failed?
>>
>
> Here:
> https://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/24130/
>
> The next build passed.
>
> Maybe we need to solve the flakiness of some tests by running a flaky test
> again, and let the build fail only if a test failed twice. I wonder if
> there is some
> pytest plugin doing this.
>
>
>>
>>
>>>
>>> *14:19:02* 
>>> ==*14:19:02*
>>>  ERROR:
>>>
>>> *14:19:02* 
>>> --*14:19:02*
>>>  Traceback (most recent call last):*14:19:02*   File 
>>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/testlib.py",
>>>  line 143, in wrapper*14:19:02* return f(self, *args)*14:19:02*   File 
>>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/stomp_test.py",
>>>  line 95, in test_echo*14:19:02* str(uuid4())),*14:19:02*   File 
>>> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/lib/yajsonrpc/jsonrpcclient.py",
>>>  line 77, in callMethod*14:19:02* raise 
>>> exception.JsonRpcNoResponseError(method=methodName)*14:19:02* 
>>> JsonRpcNoResponseError: No response for JSON-RPC request: {'method': 
>>> 'echo'}*14:19:02*  >> begin captured logging << 
>>> *14:19:02* 2018-06-27 14:17:54,524 DEBUG (MainThread) 
>>> [vds.MultiProtocolAcceptor] Creating socket (host='::1', port=0, family=10, 
>>> socketype=1, proto=6) (protocoldetector:225)*14:19:02* 2018-06-27 
>>> 14:17:54,526 INFO  (MainThread) [vds.MultiProtocolAcceptor] Listening at 
>>> ::1:36713 (protocoldetector:183)*14:19:02* 2018-06-27 14:17:54,535 DEBUG 
>>> (MainThread) [Scheduler] Starting scheduler test.Scheduler 
>>> (schedule:98)*14:19:02* 2018-06-27 14:17:54,537 DEBUG (test.Scheduler) 
>>> [Scheduler] START thread >> 140562082535168)> (func=>> >, args=(), kwargs={}) 
>>> (concurrent:193)*14:19:02* 2018-06-27 14:17:54,538 DEBUG (test.Scheduler) 
>>> [Scheduler] started (schedule:140)*14:19:02* 2018-06-27 14:17:54,546 DEBUG 
>>> (JsonRpc (StompReactor)) [root] START thread >> (StompReactor), started daemon 140562629256960)> (func=>> StompReactor.process_requests of >> at 0x7fd74ca006d0>>, args=(), kwargs={}) (concurrent:193)*14:19:02* 
>>> 2018-06-27 14:17:54,547 DEBUG (MainThread) [Executor] Starting executor 
>>> (executor:128)*14:19:02* 2018-06-27 14:17:54,549 DEBUG (MainThread) 
>>> [Executor] Starting worker jsonrpc/0 (executor:286)*14:19:02* 2018-06-27 
>>> 14:17:54,553 DEBUG (jsonrpc/0) [Executor] START thread >> started daemon 140562612471552)> (func=>> >, args=(), 
>>> kwargs={}) (concurrent:193)*14:19:02* 2018-06-27 14:17:54,554 DEBUG 
>>> (jsonrpc/0) [Executor] Worker started (executor:298)*14:19:02* 2018-06-27 
>>> 14:17:54,557 DEBUG (MainThread) [Executor] Starting worker jsonrpc/1 
>>> (executor:286)*14:19:02* 2018-06-27 14:17:54,558 DEBUG (MainThread) 
>>> [Executor] Starting worker jsonrpc/2 (executor:286)*14:19:02* 2018-06-27 
>>> 14:17:54,559 DEBUG (jsonrpc/2) [Executor] START thread >> started daemon 140562620864256)> (func=>> >, args=(), 
>>> kwargs={}) (concurrent:193)*14:19:02* 2018-06-27 14:17:54,560 DEBUG 
>>> (jsonrpc/2) [Executor] Worker started (executor:298)*14:19:02* 2018-06-27 
>>> 14:17:54,561 DEBUG (MainThread) [Executor] Starting worker jsonrpc/3 
>>> (executor:286)*14:19:02* 2018-06-27 14:17:54,562 DEBUG (jsonrpc/3) 
>>> [Executor] START thread  
>>> (func=>> at 0x7fd74bc80290>>, args=(), kwargs={}) (concurrent:193)*14:19:02* 
>>> 2018-06-27 14:17:54,563 DEBUG (jsonrpc/3) [Executor] Worker started 
>>> (executor:298)*14:19:02* 2018-06-27 14:17:54,564 DEBUG (MainThread) 
>>> [Executor] Starting worker jsonrpc/4 (executor:286)*14:19:02* 2018-06-27 
>>> 14:17:54,565 DEBUG (jsonrpc/4) [Executor] START thread >> started daemon 140562116105984)>

[ovirt-devel] Re: [VDSM] test_echo(1024, False) (stomp_test.StompTests) fails

[Piotr Kliczewski]

On Wed, Jun 27, 2018 at 5:01 PM, Nir Soffer  wrote:

> This tests used to fail in the past, but since we fixed it or the code
>
> it never failed.
>
>
> Maybe the slave was overloaded?
>
>
Very possible. Can you paste a link to the job which failed?


>
> *14:19:02* 
> ==*14:19:02*
>  ERROR:
>
> *14:19:02* 
> --*14:19:02*
>  Traceback (most recent call last):*14:19:02*   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/testlib.py",
>  line 143, in wrapper*14:19:02* return f(self, *args)*14:19:02*   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/tests/stomp_test.py",
>  line 95, in test_echo*14:19:02* str(uuid4())),*14:19:02*   File 
> "/home/jenkins/workspace/vdsm_master_check-patch-el7-x86_64/vdsm/lib/yajsonrpc/jsonrpcclient.py",
>  line 77, in callMethod*14:19:02* raise 
> exception.JsonRpcNoResponseError(method=methodName)*14:19:02* 
> JsonRpcNoResponseError: No response for JSON-RPC request: {'method': 
> 'echo'}*14:19:02*  >> begin captured logging << 
> *14:19:02* 2018-06-27 14:17:54,524 DEBUG (MainThread) 
> [vds.MultiProtocolAcceptor] Creating socket (host='::1', port=0, family=10, 
> socketype=1, proto=6) (protocoldetector:225)*14:19:02* 2018-06-27 
> 14:17:54,526 INFO  (MainThread) [vds.MultiProtocolAcceptor] Listening at 
> ::1:36713 (protocoldetector:183)*14:19:02* 2018-06-27 14:17:54,535 DEBUG 
> (MainThread) [Scheduler] Starting scheduler test.Scheduler 
> (schedule:98)*14:19:02* 2018-06-27 14:17:54,537 DEBUG (test.Scheduler) 
> [Scheduler] START thread  140562082535168)> (func= >, args=(), kwargs={}) 
> (concurrent:193)*14:19:02* 2018-06-27 14:17:54,538 DEBUG (test.Scheduler) 
> [Scheduler] started (schedule:140)*14:19:02* 2018-06-27 14:17:54,546 DEBUG 
> (JsonRpc (StompReactor)) [root] START thread  started daemon 140562629256960)> (func= StompReactor.process_requests of  at 0x7fd74ca006d0>>, args=(), kwargs={}) (concurrent:193)*14:19:02* 
> 2018-06-27 14:17:54,547 DEBUG (MainThread) [Executor] Starting executor 
> (executor:128)*14:19:02* 2018-06-27 14:17:54,549 DEBUG (MainThread) 
> [Executor] Starting worker jsonrpc/0 (executor:286)*14:19:02* 2018-06-27 
> 14:17:54,553 DEBUG (jsonrpc/0) [Executor] START thread  started daemon 140562612471552)> (func= name=jsonrpc/0 waiting task#=0 at 0x7fd74ca00650>>, args=(), kwargs={}) 
> (concurrent:193)*14:19:02* 2018-06-27 14:17:54,554 DEBUG (jsonrpc/0) 
> [Executor] Worker started (executor:298)*14:19:02* 2018-06-27 14:17:54,557 
> DEBUG (MainThread) [Executor] Starting worker jsonrpc/1 
> (executor:286)*14:19:02* 2018-06-27 14:17:54,558 DEBUG (MainThread) 
> [Executor] Starting worker jsonrpc/2 (executor:286)*14:19:02* 2018-06-27 
> 14:17:54,559 DEBUG (jsonrpc/2) [Executor] START thread  started daemon 140562620864256)> (func= name=jsonrpc/2 waiting task#=0 at 0x7fd74c9fb350>>, args=(), kwargs={}) 
> (concurrent:193)*14:19:02* 2018-06-27 14:17:54,560 DEBUG (jsonrpc/2) 
> [Executor] Worker started (executor:298)*14:19:02* 2018-06-27 14:17:54,561 
> DEBUG (MainThread) [Executor] Starting worker jsonrpc/3 
> (executor:286)*14:19:02* 2018-06-27 14:17:54,562 DEBUG (jsonrpc/3) [Executor] 
> START thread  (func= method _Worker._run of  0x7fd74bc80290>>, args=(), kwargs={}) (concurrent:193)*14:19:02* 2018-06-27 
> 14:17:54,563 DEBUG (jsonrpc/3) [Executor] Worker started 
> (executor:298)*14:19:02* 2018-06-27 14:17:54,564 DEBUG (MainThread) 
> [Executor] Starting worker jsonrpc/4 (executor:286)*14:19:02* 2018-06-27 
> 14:17:54,565 DEBUG (jsonrpc/4) [Executor] START thread  started daemon 140562116105984)> (func= name=jsonrpc/4 waiting task#=0 at 0x7fd74bc80790>>, args=(), kwargs={}) 
> (concurrent:193)*14:19:02* 2018-06-27 14:17:54,566 DEBUG (jsonrpc/4) 
> [Executor] Worker started (executor:298)*14:19:02* 2018-06-27 14:17:54,568 
> DEBUG (jsonrpc/1) [Executor] START thread  140562132891392)> (func= waiting task#=0 at 0x7fd74c9fb690>>, args=(), kwargs={}) 
> (concurrent:193)*14:19:02* 2018-06-27 14:17:54,569 DEBUG (jsonrpc/1) 
> [Executor] Worker started (executor:298)*14:19:02* 2018-06-27 14:17:54,569 
> DEBUG (MainThread) [Executor] Starting worker jsonrpc/5 
> (executor:286)*14:19:02* 2018-06-27 14:17:54,570 DEBUG (jsonrpc/5) [Executor] 
> START thread  (func= method _Worker._run of  0x7fd74bc80090>>, args=(), kwargs={}) (concurrent:193)*14:19:02* 2018-06-27 
> 14:17:54,571 DEBUG (jsonrpc/5) [Executor] Worker started 
> (executor:298)*14:19:02* 2018-06-27 14:17:54,572 DEBUG (MainThread) 
> [Executor] Starting worker jsonrpc/6 (executor:286)*14:19:02* 2018-06-27 
> 14:17:54,580 DEBUG (MainThread) [Executor] Starting worker jsonrpc/7 
> (executor:286)*14:19:02* 2018-06-27 14:17:54,603 DEBUG (jsonrpc/6) [Executor] 
> START thread  (func= method _Worker._run of  0x7fd74d0dacd0>>, args=(), kwargs={}) 

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

[Piotr Kliczewski]

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

[ovirt-devel] Re: [ OST Failure Report ] [ oVirt master ] [ 2018-05-25 ] [AddHost]

[Piotr Kliczewski]

+Martin

He is working on it.

Thanks,
Piotr

On Tue, May 29, 2018 at 2:22 PM, Dafna Ron  wrote:

> Hi Piotr,
>
> Any update on this?
>
> Thanks.
> Dafna
>
>
> On Mon, May 28, 2018 at 10:59 AM, Piotr Kliczewski <
> piotr.kliczew...@gmail.com> wrote:
>
>> On Mon, May 28, 2018 at 11:41 AM, Barak Korren 
>> wrote:
>> >
>> >
>> > On 28 May 2018 at 12:38, Piotr Kliczewski 
>> > wrote:
>> >>
>> >> On Mon, May 28, 2018 at 10:57 AM, Barak Korren 
>> wrote:
>> >> > Note: we're now seeing a very similar issue in the 4.2 branch as well
>> >> > that
>> >> > seems to have been introduced by the following patch:
>> >>
>> >> Can you point to specific job so we could take a look at the logs?
>> >
>> >
>> > Whoops, sorry, here:
>> > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/2034/
>> >
>>
>> Looks like the same issue:
>>
>> 2018-05-28 03:41:03,606-04 ERROR
>> [org.ovirt.engine.core.uutils.ssh.SSHDialog]
>> (EE-ManagedThreadFactory-engine-Thread-1) [1244c90f] SSH error running
>> command root@lago-upgrade-from-prevrelease-suite-4-2-host-0:'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': TimeLimitExceededException: SSH
>> session timeout host
>> 'root@lago-upgrade-from-prevrelease-suite-4-2-host-0'
>> 2018-05-28 03:41:03,606-04 ERROR
>> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (VdsDeploy)
>> [1244c90f] Error during deploy dialog
>> 2018-05-28 03:41:03,611-04 ERROR
>> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase]
>> (EE-ManagedThreadFactory-engine-Thread-1) [1244c90f] Timeout during
>> host lago-upgrade-from-prevrelease-suite-4-2-host-0 install: SSH
>> session timeout host
>> 'root@lago-upgrade-from-prevrelease-suite-4-2-host-0'
>>
>> >>
>> >>
>> >> >
>> >> > https://gerrit.ovirt.org/c/91638/2 - core: Enable only strong
>> ciphers
>> >> > for
>> >> > 4.2 hosts
>> >> >
>> >> > On 28 May 2018 at 10:26, Barak Korren  wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On 28 May 2018 at 10:19, Martin Perina  wrote:
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> On Mon, May 28, 2018 at 9:00 AM, Piotr Kliczewski
>> >> >>> 
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> Simone,
>> >> >>>>
>> >> >>>> What do you think about this failure?
>> >> >>>>
>> >> >>>> Thanks,
>> >> >>>> Piotr
>> >> >>>>
>> >> >>>> On Mon, May 28, 2018 at 7:12 AM, Barak Korren > >
>> >> >>>> wrote:
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> On 27 May 2018 at 14:59, Piotr Kliczewski 
>> >> >>>>> wrote:
>> >> >>>>>>
>> >> >>>>>> Martin,
>> >> >>>>>>
>> >> >>>>>> I only can see:
>> >> >>>>>>
>> >> >>>>>> 2018-05-25 13:57:44,255-04 ERROR
>> >> >>>>>> [org.ovirt.engine.core.uutils.ssh.SSHDialog]
>> >> >>>>>> (EE-ManagedThreadFactory-engine-Thread-1) [55a7b15b] SSH error
>> >> >>>>>> running
>> >> >>>>>> command root@lago-upgrade-from-release
>> -suite-master-host-0:'umask
>> >> >>>>>> 0077;
>> >> >>>>>> MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t
>> ovirt-XX)";
>> >> >>>>>> trap
>> >> >>>>>> "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr
>> \"${MYTMP}\"
>> >> >>>>>> >
>> >

[ovirt-devel] Re: [ OST Failure Report ] [ oVirt master ] [ 2018-05-25 ] [AddHost]

[Piotr Kliczewski]

On Mon, May 28, 2018 at 11:41 AM, Barak Korren <bkor...@redhat.com> wrote:
>
>
> On 28 May 2018 at 12:38, Piotr Kliczewski <piotr.kliczew...@gmail.com>
> wrote:
>>
>> On Mon, May 28, 2018 at 10:57 AM, Barak Korren <bkor...@redhat.com> wrote:
>> > Note: we're now seeing a very similar issue in the 4.2 branch as well
>> > that
>> > seems to have been introduced by the following patch:
>>
>> Can you point to specific job so we could take a look at the logs?
>
>
> Whoops, sorry, here:
> http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/2034/
>

Looks like the same issue:

2018-05-28 03:41:03,606-04 ERROR
[org.ovirt.engine.core.uutils.ssh.SSHDialog]
(EE-ManagedThreadFactory-engine-Thread-1) [1244c90f] SSH error running
command root@lago-upgrade-from-prevrelease-suite-4-2-host-0:'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': TimeLimitExceededException: SSH
session timeout host
'root@lago-upgrade-from-prevrelease-suite-4-2-host-0'
2018-05-28 03:41:03,606-04 ERROR
[org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (VdsDeploy)
[1244c90f] Error during deploy dialog
2018-05-28 03:41:03,611-04 ERROR
[org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase]
(EE-ManagedThreadFactory-engine-Thread-1) [1244c90f] Timeout during
host lago-upgrade-from-prevrelease-suite-4-2-host-0 install: SSH
session timeout host
'root@lago-upgrade-from-prevrelease-suite-4-2-host-0'

>>
>>
>> >
>> > https://gerrit.ovirt.org/c/91638/2 - core: Enable only strong ciphers
>> > for
>> > 4.2 hosts
>> >
>> > On 28 May 2018 at 10:26, Barak Korren <bkor...@redhat.com> wrote:
>> >>
>> >>
>> >>
>> >> On 28 May 2018 at 10:19, Martin Perina <mper...@redhat.com> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Mon, May 28, 2018 at 9:00 AM, Piotr Kliczewski
>> >>> <pklic...@redhat.com>
>> >>> wrote:
>> >>>>
>> >>>> Simone,
>> >>>>
>> >>>> What do you think about this failure?
>> >>>>
>> >>>> Thanks,
>> >>>> Piotr
>> >>>>
>> >>>> On Mon, May 28, 2018 at 7:12 AM, Barak Korren <bkor...@redhat.com>
>> >>>> wrote:
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On 27 May 2018 at 14:59, Piotr Kliczewski <pklic...@redhat.com>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> Martin,
>> >>>>>>
>> >>>>>> I only can see:
>> >>>>>>
>> >>>>>> 2018-05-25 13:57:44,255-04 ERROR
>> >>>>>> [org.ovirt.engine.core.uutils.ssh.SSHDialog]
>> >>>>>> (EE-ManagedThreadFactory-engine-Thread-1) [55a7b15b] SSH error
>> >>>>>> running
>> >>>>>> command root@lago-upgrade-from-release-suite-master-host-0:'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': TimeLimitExceededException: SSH
>> >>>>>> session
>> >>>>>> timeout host 'root@lago-upgrade-from-release-suite-master-host-0'
>> >>>>>> 2018-05-25 13:57:44,259-04 ERROR
>> >>>>>> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase]
>> >>>>>> (EE-ManagedThreadFactory-engine-Thread-1) [55a7b15b] Timeout during
>> >>>>>> host
>> >>>>>> lago-upgrade-from-release-suite-master-host-0 install: SSH session
>> >>>>>> timeout
>> >>>>>> hos

[ovirt-devel] Re: [ OST Failure Report ] [ oVirt master ] [ 2018-05-25 ] [AddHost]

[Piotr Kliczewski]

On Mon, May 28, 2018 at 10:57 AM, Barak Korren <bkor...@redhat.com> wrote:
> Note: we're now seeing a very similar issue in the 4.2 branch as well that
> seems to have been introduced by the following patch:

Can you point to specific job so we could take a look at the logs?

>
> https://gerrit.ovirt.org/c/91638/2 - core: Enable only strong ciphers for
> 4.2 hosts
>
> On 28 May 2018 at 10:26, Barak Korren <bkor...@redhat.com> wrote:
>>
>>
>>
>> On 28 May 2018 at 10:19, Martin Perina <mper...@redhat.com> wrote:
>>>
>>>
>>>
>>> On Mon, May 28, 2018 at 9:00 AM, Piotr Kliczewski <pklic...@redhat.com>
>>> wrote:
>>>>
>>>> Simone,
>>>>
>>>> What do you think about this failure?
>>>>
>>>> Thanks,
>>>> Piotr
>>>>
>>>> On Mon, May 28, 2018 at 7:12 AM, Barak Korren <bkor...@redhat.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 27 May 2018 at 14:59, Piotr Kliczewski <pklic...@redhat.com> wrote:
>>>>>>
>>>>>> Martin,
>>>>>>
>>>>>> I only can see:
>>>>>>
>>>>>> 2018-05-25 13:57:44,255-04 ERROR
>>>>>> [org.ovirt.engine.core.uutils.ssh.SSHDialog]
>>>>>> (EE-ManagedThreadFactory-engine-Thread-1) [55a7b15b] SSH error running
>>>>>> command root@lago-upgrade-from-release-suite-master-host-0:'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': TimeLimitExceededException: SSH session
>>>>>> timeout host 'root@lago-upgrade-from-release-suite-master-host-0'
>>>>>> 2018-05-25 13:57:44,259-04 ERROR
>>>>>> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase]
>>>>>> (EE-ManagedThreadFactory-engine-Thread-1) [55a7b15b] Timeout during host
>>>>>> lago-upgrade-from-release-suite-master-host-0 install: SSH session 
>>>>>> timeout
>>>>>> host 'root@lago-upgrade-from-release-suite-master-host-0'
>>>>>>
>>>>>> There are no additional logs. SSH to host timeout. Are we sure that it
>>>>>> is an issue caused by Ravi's change?
>>>>>
>>>>>
>>>>> We have some quite strong circumstantial evidence:
>>>>> - Issue had affected all engine patches since that patch in a similar
>>>>> fashion.
>>>>> - Prior engine patch [1] passed successfully [2]
>>>>> - Other subsequent OST runs without engine patches passed successfully
>>>>> as well [3].
>>>>>
>>>>> [1]: https://gerrit.ovirt.org/c/91595/2
>>>>> [2]:
>>>>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester//
>>>>> [3]:
>>>>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7778/
>>>>>
>>>>>
>>>>> Please note - the issue is affecting a test that is run by an upgrade
>>>>> suit on the post-upgrade system. It has no affect on the basic suit. So it
>>>>> probably has to do with some behaviour that is specific to upgraded 
>>>>> systems.
>>>
>>>
>>> I will try to reproduce later today in dev env, but I agree with Piotr's
>>> investigation, engine was not able to connect to the host using SSH and
>>> that's why no host-deploy logs were fetched.
>>
>>
>> Lago fetches the logs from the host too (And it can take then from the VM
>> image directly if the host is not responsive over SSH), can we get at the
>> host-deploy logs that way?
>>
>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Piotr
>>>>>>
>>>>>> On Sun, May 27, 2018 at 11:21 AM, Martin Perina <mper...@redhat.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Adding also Piotr to the thread
>>>>>>>
>&

[ovirt-devel] Re: [ OST Failure Report ] [ oVirt master ] [ 2018-05-25 ] [AddHost]

[Piotr Kliczewski]

Simone,

What do you think about this failure?

Thanks,
Piotr

On Mon, May 28, 2018 at 7:12 AM, Barak Korren <bkor...@redhat.com> wrote:

>
>
> On 27 May 2018 at 14:59, Piotr Kliczewski <pklic...@redhat.com> wrote:
>
>> Martin,
>>
>> I only can see:
>>
>> 2018-05-25 13:57:44,255-04 ERROR 
>> [org.ovirt.engine.core.uutils.ssh.SSHDialog] 
>> (EE-ManagedThreadFactory-engine-Thread-1) [55a7b15b] SSH error running 
>> command root@lago-upgrade-from-release-suite-master-host-0:'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': TimeLimitExceededException: SSH session 
>> timeout host 'root@lago-upgrade-from-release-suite-master-host-0'
>> 2018-05-25 13:57:44,259-04 ERROR 
>> [org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] 
>> (EE-ManagedThreadFactory-engine-Thread-1) [55a7b15b] Timeout during host 
>> lago-upgrade-from-release-suite-master-host-0 install: SSH session timeout 
>> host 'root@lago-upgrade-from-release-suite-master-host-0'
>>
>> There are no additional logs. SSH to host timeout. Are we sure that it is
>> an issue caused by Ravi's change?
>>
>
> We have some quite strong circumstantial evidence:
> - Issue had affected all engine patches since that patch in a similar
> fashion.
> - Prior engine patch [1] passed successfully [2]
> - Other subsequent OST runs without engine patches passed successfully as
> well [3].
>
> [1]: https://gerrit.ovirt.org/c/91595/2
> [2]: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester//
> [3]: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7778/
>
>
> Please note - the issue is affecting a test that is run by an upgrade suit
> on the post-upgrade system. It has no affect on the basic suit. So it
> probably has to do with some behaviour that is specific to upgraded
> systems.
>
>
>
>>
>> Thanks,
>> Piotr
>>
>> On Sun, May 27, 2018 at 11:21 AM, Martin Perina <mper...@redhat.com>
>> wrote:
>>
>>> Adding also Piotr to the thread
>>>
>>>
>>> On Sun, 27 May 2018, 08:46 Barak Korren, <bkor...@redhat.com> wrote:
>>>
>>>> Test failed: [ AddHost (in upgrade-from-release-suite) ]
>>>>
>>>> Link to suspected patches:
>>>> https://gerrit.ovirt.org/#/c/91445/5 - Disable TLS versions < 1.2 for
>>>> hosts with cluster level>=4.1
>>>>
>>>> Link to Job:
>>>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7776/
>>>>
>>>> Link to all logs:
>>>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-teste
>>>> r/7776/artifact/exported-artifacts/upgrade-from-release-suit
>>>> -master-el7/test_logs/upgrade-from-release-suite-master/
>>>> post-002_bootstrap.py/
>>>>
>>>> Error snippet from log:
>>>>
>>>> From nosetst log:
>>>> 
>>>>
>>>> AssertionError: False != True after 1200 seconds
>>>>
>>>> 
>>>>
>>>> Not finding a host deploy log in /var/log/ovirt-engine for some reason.
>>>> This seems to have cause consistent failure in all other engine patches
>>>> that followed it.
>>>>
>>>>
>>>> --
>>>> Barak Korren
>>>> RHV DevOps team , RHCE, RHCi
>>>> Red Hat EMEA
>>>> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>>>>
>>>
>>
>
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>
___
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/3PZIODJE2Y34IDHA64ZX7AVG6FMJCRAM/

[ovirt-devel] Re: [ OST Failure Report ] [ oVirt master ] [ 2018-05-25 ] [AddHost]

[Piotr Kliczewski]

Martin,

I only can see:

2018-05-25 13:57:44,255-04 ERROR
[org.ovirt.engine.core.uutils.ssh.SSHDialog]
(EE-ManagedThreadFactory-engine-Thread-1) [55a7b15b] SSH error running
command root@lago-upgrade-from-release-suite-master-host-0:'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': TimeLimitExceededException: SSH
session timeout host
'root@lago-upgrade-from-release-suite-master-host-0'
2018-05-25 13:57:44,259-04 ERROR
[org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase]
(EE-ManagedThreadFactory-engine-Thread-1) [55a7b15b] Timeout during
host lago-upgrade-from-release-suite-master-host-0 install: SSH
session timeout host
'root@lago-upgrade-from-release-suite-master-host-0'

There are no additional logs. SSH to host timeout. Are we sure that it is
an issue caused by Ravi's change?

Thanks,
Piotr

On Sun, May 27, 2018 at 11:21 AM, Martin Perina  wrote:

> Adding also Piotr to the thread
>
>
> On Sun, 27 May 2018, 08:46 Barak Korren,  wrote:
>
>> Test failed: [ AddHost (in upgrade-from-release-suite) ]
>>
>> Link to suspected patches:
>> https://gerrit.ovirt.org/#/c/91445/5 - Disable TLS versions < 1.2 for
>> hosts with cluster level>=4.1
>>
>> Link to Job:
>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/7776/
>>
>> Link to all logs:
>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-
>> tester/7776/artifact/exported-artifacts/upgrade-from-
>> release-suit-master-el7/test_logs/upgrade-from-release-
>> suite-master/post-002_bootstrap.py/
>>
>> Error snippet from log:
>>
>> From nosetst log:
>> 
>>
>> AssertionError: False != True after 1200 seconds
>>
>> 
>>
>> Not finding a host deploy log in /var/log/ovirt-engine for some reason.
>> This seems to have cause consistent failure in all other engine patches
>> that followed it.
>>
>>
>> --
>> Barak Korren
>> RHV DevOps team , RHCE, RHCi
>> Red Hat EMEA
>> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org

[ovirt-devel] Re: ovirt-engine travis CI

[Piotr Kliczewski]

On Wed, May 16, 2018 at 4:38 PM, Sandro Bonazzola 
wrote:

>
>
> 2018-05-16 16:26 GMT+02:00 Yaniv Kaul :
>
>>
>>
>> On Wed, May 16, 2018 at 5:12 PM, Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> 2018-05-16 15:56 GMT+02:00 Yaniv Kaul :
>>>


 On Wed, May 16, 2018 at 4:04 PM, Barak Korren 
 wrote:

>
>
> On 16 May 2018 at 11:03, Sandro Bonazzola  wrote:
>
>> Hi,
>> today I pushed a fix for Travis CI on oVirt Engine. While discussing
>> the fix it has been asked why we need Travis CI in first place, isn't our
>> Jenkins testing enough?
>>
>>
> I'm wondering that as well...
>

 What does it do that we don't do on our CI?

>>>
>>> commit 0734e8cb9c7d1411b613f1262e81c6845b18f5d9
>>> Author: Roman Mohr 
>>> Date:   Mon Jul 18 12:08:59 2016 +0200
>>>
>>> Sonarqube moved to https://sonarqube.com
>>>
>>> Change-Id: I1ce975222845bed6836464bbf73732bbcb9eff1d
>>> Signed-off-by: Roman Mohr 
>>>
>>> commit c703d194a4ed84541fb16b0aec73f1597ceaa05f
>>> Author: Roman Mohr 
>>> Date:   Fri Jun 3 08:28:56 2016 +0200
>>>
>>> Print a keep alive message every minute on travis builds
>>>
>>> For one hour print every minute a keep alive message to stdout to
>>> keep
>>> the travis job alive.
>>>
>>> Sonar analysis takes more than 10 minutes. In this time period no
>>> output
>>> is produced. Travis assumes that builds are somehow broken if there
>>> was
>>> no output for more than 10 minutes.
>>>
>>> Change-Id: Ia2d048e42ee410eb72a35f2793935757308c7765
>>> Signed-off-by: Roman Mohr 
>>>
>>> commit fe4743ce5ffadb663d3fda58d09e9906b35b91ee
>>> Author: Roman Mohr 
>>> Date:   Wed May 25 17:05:04 2016 +0200
>>>
>>> Limit sonar analysis to master branch
>>>
>>> Sonar by default does not differentiate between different branches.
>>> Limit the analysis to master to get untainted reports.
>>>
>>> Change-Id: Icab31f0aaf98adc88214ed70d7276f13eac188ee
>>> Signed-off-by: Roman Mohr 
>>>
>>> According to commit 768154debecccbc93524cd4e6c5092047d2a4eab by Roman
>>> Mohr on Sat May 7 05:39:18 2016 +0200
>>> it's doing Sonar code analysis on travis and then upload the results to
>>> sonarqube.org
>>> It generates this report: https://sonarcloud.io/
>>> dashboard?id=org.ovirt.engine%3Aroot
>>> Which has been updated last time on November 21, 2017 probably due to
>>> the switch to PostgreSQL 9.5
>>> I've no rights on that report, maybe Roman can grant some more
>>> privileges so I can try to get it back to work if needed.
>>>
>>>
>>>
 What was broken there?

>>>
>>> It's failing on DAO tests.
>>> It was failing initializing the database because it was still using
>>> postgresql 9.2 instead of 9.5.
>>> Now it's failing on missing  uuid_generate_v1() function.
>>>
>>>
>>>
 Can it replace some of what we do in our CI (and does it have value, as
 it is a mirror of published code already) ?

>>>
>>> As far as I can tell the only gain is the sonarqube analysis of the
>>> code. I'm not sure if we can integrate this with Jenkins.
>>>
>>
>> Who's looking at the analysis results?
>>
>
> Being it analyzing only the ovirt-engine java code I would expect backend
> maintainers should keep an eye on it.
> Digging the mailing list history looks like this was discussed and
> approved in 2016
> The most interested person back to that time was Piotr: are you looking at
> it?
>

No, I am not looking at it. It is something I need to improve


>
>
> https://lists.ovirt.org/archives/list/devel@ovirt.org/thread/
> EZ3ASOZAS3OBVSGR54Q6PT6NB57YCCS4/#EZ3ASOZAS3OBVSGR54Q6PT6NB57YCCS4
> https://lists.ovirt.org/archives/list/in...@ovirt.org/thread/
> VDAPFW2YVNJWU2T6WKPK7Q2Y4HY34KPW/#EQGLKDFWNEBBIOIMODCNZGX6CIE2XZIV
>
>
>
>
>> Y.
>>
>>
>>>
>>>
>>>
>>>
>>>
 Y.


>
>
>
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>
> ___
> Infra mailing list -- in...@ovirt.org
> To unsubscribe send an email to infra-le...@ovirt.org
>
>

>>>
>>>
>>> --
>>>
>>> SANDRO BONAZZOLA
>>>
>>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>>>
>>> Red Hat EMEA 
>>>
>>> sbona...@redhat.com
>>> 
>>> 
>>>
>>
>>
>
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
> 
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an 

[ovirt-devel] Re: [ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 10-05-2018 ] [ 001_upgrade_engine.test_initialize_engine ]

[Piotr Kliczewski]

Dafna,

I usually trigger [1]. Is there anything new I need to do to make sure that
the rpm is published?

Thanks,
Piotr

[1]
http://jenkins.ovirt.org/job/vdsm-jsonrpc-java_any_build-artifacts-manual/55/

On Fri, May 11, 2018 at 12:20 PM, Dafna Ron  wrote:

> Hi,
>
> This change is still in the queue.
>
> thanks,
> Dafna
>
>
>
>
> On Thu, May 10, 2018 at 3:22 PM, Eyal Edri  wrote:
>
>> I think the version bump was merged by Piotr [1] ,it just didn't pass yet
>> on CQ.
>> Barak/Dafna - can you confirm?
>>
>> https://gerrit.ovirt.org/#/c/91081/
>>
>> On Thu, May 10, 2018 at 3:19 PM, Martin Perina 
>> wrote:
>>
>>> On Thu, May 10, 2018 at 1:55 PM, Dafna Ron  wrote:
>>>
>>> > Hi,
>>> >
>>> > We are failing on deploying engine (test:
>>> 001_upgrade_engine.test_initialize_engine)
>>> > duet to version bump for package vdsm-jsonrpc.
>>> >
>>> > Can you please revert the change or add the missing package?
>>> > Please note that all ovirt-engine changes are failing and there are a
>>> few
>>>
>>
>>
>>
>> --
>>
>> Eyal edri
>>
>>
>> MANAGER
>>
>> RHV DevOps
>>
>> EMEA VIRTUALIZATION R
>>
>>
>> Red Hat EMEA 
>>  TRIED. TESTED. TRUSTED. 
>> phone: +972-9-7692018
>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>
>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

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

[Piotr Kliczewski]

+1

On Tue, May 1, 2018 at 11:33 PM, Martin Perina  wrote:
>
>
> On Tue, May 1, 2018 at 9:54 AM, Alona Kaplan  wrote:
>>
>> Hi all,
>>
>> Dominik Holler has been working on the oVirt project for more than 1.5
>> years.
>>
>> To share some of Dominik's great stats -
>> ~ 120 patches related to the network backend/ui
>> ~ 95 patches for ovirt-provider-ovn
>> ~ 44 vdsm patches
>> ~ 80 bug fixes
>>
>> He was the feature owner of 'auto sync network provider', 'lldp-reporting'
>> and 'network-filter-parameters'.
>>
>> For the last few months Dominik is helping review network-backend related
>> patches and is doing a great and thorough work.
>> Dominik showed a deep understanding of all the parts of code that he
>> touched or reviewed.
>> He learns fast, thorough and uncompromising.
>>
>> I've reviewed most of Dominik's engine related work (code and reviews).
>> I trust his opinion and think he will be a good addition to the
>> maintainers team.
>>
>> I would like to propose Dominik as a Network backend maintainer.
>
>
> +1 from me
>
>>
>>
>>
>> Thanks,
>> Alona.
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
>
> --
> Martin Perina
> Associate Manager, Software Engineering
> Red Hat Czech s.r.o.
>
> ___
> 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 4.2 ] [ 2018-04-04 ] [006_migrations.prepare_migration_attachments_ipv6]

[Piotr Kliczewski]

śr., 25 kwi 2018, 19:07 użytkownik Martin Perina 
napisał:

> Ravi/Piotr, so what's the connection between non-blocking threads,
> jsonrpc-java connection closing and failing this network test? Does it mean
> that non-blocking threads change just revealed the jsonrpc-java issue which
> we haven't noticed before?
> And did the test really works with code prior to non-blocking threads
> changes and we are missing something else?
>

I think that the test found something not related to non-blocking threads.
This behavior was in the code since the beginning.


>
> On Wed, 25 Apr 2018, 18:21 Ravi Shankar Nori,  wrote:
>
>>
>>
>> On Wed, Apr 25, 2018 at 10:57 AM, Martin Perina 
>> wrote:
>>
>>>
>>>
>>> On Tue, Apr 24, 2018 at 3:28 PM, Dan Kenigsberg 
>>> wrote:
>>>
 On Tue, Apr 24, 2018 at 4:17 PM, Ravi Shankar Nori 
 wrote:
 >
 >
 > On Tue, Apr 24, 2018 at 7:00 AM, Dan Kenigsberg 
 wrote:
 >>
 >> Ravi's patch is in, but a similar problem remains, and the test
 cannot
 >> be put back into its place.
 >>
 >> It seems that while Vdsm was taken down, a couple of getCapsAsync
 >> requests queued up. At one point, the host resumed its connection,
 >> before the requests have been cleared of the queue. After the host is
 >> up, the following tests resume, and at a pseudorandom point in time,
 >> an old getCapsAsync request times out and kills our connection.
 >>
 >> I believe that as long as ANY request is on flight, the monitoring
 >> lock should not be released, and the host should not be declared as
 >> up.
 >>
 >>
 >
 >
 > Hi Dan,
 >
 > Can I have the link to the job on jenkins so I can look at the logs

 We disabled a network test that started failing after getCapsAsync was
 merged.
 Please own its re-introduction to OST:
 https://gerrit.ovirt.org/#/c/90264/

 Its most recent failure

 http://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/346/
 has been discussed by Alona and Piotr over IRC.

>>>
>>> ​So https://bugzilla.redhat.com/1571768 was created to cover this
>>> issue​ discovered during Alona's and Piotr's conversation. But after
>>> further discussion we have found out that this issue is not related to
>>> non-blocking thread changes in engine 4.2 and this behavior exists from
>>> beginning of vdsm-jsonrpc-java. Ravi will continue verify the fix for
>>> BZ1571768 along with other locking changes he already posted to see if they
>>> will help network OST to succeed.
>>>
>>> But the fix for BZ1571768 is too dangerous for 4.2.3, let's try to fix
>>> that on master and let's see if it doesn't introduce any regressions. If
>>> not, then we can backport to 4.2.4.
>>>
>>>
>>>
>>> --
>>> Martin Perina
>>> Associate Manager, Software Engineering
>>> Red Hat Czech s.r.o.
>>>
>>
>> Posted a vdsm-jsonrpc-java patch [1] for BZ 1571768 [2] which fixes the
>> OST issue with enabling 006_migrations.prepare_migration_attachments_ipv6.
>>
>> I ran OST with the vdsm-jsonrpc-java patch [1] and the patch to add back
>> 006_migrations.prepare_migration_attachments_ipv6 [3]  and the jobs
>> succeeded thrice [4][5][6]
>>
>> [1] https://gerrit.ovirt.org/#/c/90646/
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1571768
>> [3] https://gerrit.ovirt.org/#/c/90264/
>> [4] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/2643/
>> [5] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/2644/
>> [6] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/2645/
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Name resolution not working after vdsm installation

[Piotr Kliczewski]

On Wed, Apr 25, 2018 at 3:43 PM, Dan Kenigsberg  wrote:
>
> Sorry for breaking your use case.
> Marcin can show you how to write an ifcfg hook which reinroduces IPV6_
> entries to the ifcfg file.

It is enough to add ipv4 nameserver to resolv.conf to workaround the issue.

>
> We never supported IPV6 default route; but I would have expected add
> host flow to at least maintain your autoconf.
> Could you file a bug with your *vdsm.log and engine.log from the time
> of add-host?

Here is the BZ [1]

[1] https://bugzilla.redhat.com/1571869
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Name resolution not working after vdsm installation

[Piotr Kliczewski]

On Wed, Apr 25, 2018 at 11:45 AM, Martin Sivak <msi...@redhat.com> wrote:
> IPv6 only DNS? Cool (if it works) :)

It used to :)

>
> Martin
>
> On Wed, Apr 25, 2018 at 11:43 AM, Piotr Kliczewski
> <piotr.kliczew...@gmail.com> wrote:
>> In addition here is my resolv.conf
>>
>> ; generated by /usr/sbin/dhclient-script
>> nameserver 2001:730:3ed2::53
>> nameserver 2001:730:3ed2:1000::53
>> search localdomain
>>
>> On Wed, Apr 25, 2018 at 11:26 AM, Piotr Kliczewski
>> <piotr.kliczew...@gmail.com> wrote:
>>> All,
>>>
>>> I am using latest engine and vdsm 4.20.23-1. I installed vdsm on
>>> centos7 vm and after the installation my vm stopped resolving names.
>>>
>>> Here is my nic configuration before installation:
>>>
>>> TYPE="Ethernet"
>>> BOOTPROTO="dhcp"
>>> DEFROUTE="yes"
>>> PEERDNS="yes"
>>> PEERROUTES="yes"
>>> IPV4_FAILURE_FATAL="no"
>>> IPV6INIT="yes"
>>> IPV6_AUTOCONF="yes"
>>> IPV6_DEFROUTE="yes"
>>> IPV6_PEERDNS="yes"
>>> IPV6_PEERROUTES="yes"
>>> IPV6_FAILURE_FATAL="no"
>>> NAME="eth0"
>>> UUID="0079668a-8708-46ad-8dbf-da418ae6f77e"
>>> DEVICE="eth0"
>>> ONBOOT="yes"
>>>
>>> here is after:
>>>
>>> # Generated by VDSM version 4.20.23-1.el7.centos
>>> DEVICE=eth0
>>> BRIDGE=ovirtmgmt
>>> ONBOOT=yes
>>> MTU=1500
>>> DEFROUTE=no
>>> NM_CONTROLLED=no
>>> IPV6INIT=no
>>>
>>> and the bridge:
>>> # Generated by VDSM version 4.20.23-1.el7.centos
>>> DEVICE=ovirtmgmt
>>> TYPE=Bridge
>>> DELAY=0
>>> STP=off
>>> ONBOOT=yes
>>> BOOTPROTO=dhcp
>>> MTU=1500
>>> DEFROUTE=yes
>>> NM_CONTROLLED=no
>>> IPV6INIT=yes
>>> DHCPV6C=yes
>>> IPV6_AUTOCONF=no
>>>
>>> Thanks,
>>> Piotr
>> ___
>> 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] Name resolution not working after vdsm installation

[Piotr Kliczewski]

In addition here is my resolv.conf

; generated by /usr/sbin/dhclient-script
nameserver 2001:730:3ed2::53
nameserver 2001:730:3ed2:1000::53
search localdomain

On Wed, Apr 25, 2018 at 11:26 AM, Piotr Kliczewski
<piotr.kliczew...@gmail.com> wrote:
> All,
>
> I am using latest engine and vdsm 4.20.23-1. I installed vdsm on
> centos7 vm and after the installation my vm stopped resolving names.
>
> Here is my nic configuration before installation:
>
> TYPE="Ethernet"
> BOOTPROTO="dhcp"
> DEFROUTE="yes"
> PEERDNS="yes"
> PEERROUTES="yes"
> IPV4_FAILURE_FATAL="no"
> IPV6INIT="yes"
> IPV6_AUTOCONF="yes"
> IPV6_DEFROUTE="yes"
> IPV6_PEERDNS="yes"
> IPV6_PEERROUTES="yes"
> IPV6_FAILURE_FATAL="no"
> NAME="eth0"
> UUID="0079668a-8708-46ad-8dbf-da418ae6f77e"
> DEVICE="eth0"
> ONBOOT="yes"
>
> here is after:
>
> # Generated by VDSM version 4.20.23-1.el7.centos
> DEVICE=eth0
> BRIDGE=ovirtmgmt
> ONBOOT=yes
> MTU=1500
> DEFROUTE=no
> NM_CONTROLLED=no
> IPV6INIT=no
>
> and the bridge:
> # Generated by VDSM version 4.20.23-1.el7.centos
> DEVICE=ovirtmgmt
> TYPE=Bridge
> DELAY=0
> STP=off
> ONBOOT=yes
> BOOTPROTO=dhcp
> MTU=1500
> DEFROUTE=yes
> NM_CONTROLLED=no
> IPV6INIT=yes
> DHCPV6C=yes
> IPV6_AUTOCONF=no
>
> Thanks,
> Piotr
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] Installing vdsm on f27

[Piotr Kliczewski]

All,

I attempted to install vdsm on my f27 machine but I failed due to
missing dependency. I was unable to find
rubygem-fluent-plugin-elasticsearch. I used upstream repos and was not
able to find it. From where a user can get it?

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

[ovirt-devel] Name resolution not working after vdsm installation

[Piotr Kliczewski]

All,

I am using latest engine and vdsm 4.20.23-1. I installed vdsm on
centos7 vm and after the installation my vm stopped resolving names.

Here is my nic configuration before installation:

TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_PEERDNS="yes"
IPV6_PEERROUTES="yes"
IPV6_FAILURE_FATAL="no"
NAME="eth0"
UUID="0079668a-8708-46ad-8dbf-da418ae6f77e"
DEVICE="eth0"
ONBOOT="yes"

here is after:

# Generated by VDSM version 4.20.23-1.el7.centos
DEVICE=eth0
BRIDGE=ovirtmgmt
ONBOOT=yes
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
IPV6INIT=no

and the bridge:
# Generated by VDSM version 4.20.23-1.el7.centos
DEVICE=ovirtmgmt
TYPE=Bridge
DELAY=0
STP=off
ONBOOT=yes
BOOTPROTO=dhcp
MTU=1500
DEFROUTE=yes
NM_CONTROLLED=no
IPV6INIT=yes
DHCPV6C=yes
IPV6_AUTOCONF=no

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

Re: [ovirt-devel] Broken repoclosure in today 4.2.3 RC2 compose

[Piotr Kliczewski]

Sandro,

Patch [1] pushed.

Thanks,
Piotr

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

On Wed, Apr 18, 2018 at 2:14 PM, Sandro Bonazzola 
wrote:

> Hi,
>
> today oVirt 4.2.3 RC2 release is blocked on repository closure error detected 
> by ovirt-engine-appliance build:
>
>
> 13:49:14 11:49:13,944 INFO program:Error: Package: 
> ovirt-engine-backend-4.2.3.2-1.el7.centos.noarch (ovirt-4.2-pre)13:49:14 
> 11:49:13,946 INFO program:Requires: vdsm-jsonrpc-java >= 1.4.1213:49:14 
> 11:49:13,947 INFO program:Available: vdsm-jsonrpc-java-1.4.11-1.el7.noarch 
> (ovirt-4.2-centos-ovirt42)13:49:14 11:49:13,949 INFO 
> program:vdsm-jsonrpc-java = 1.4.11-1.el713:49:14 11:49:13,950 INFO 
> program:Available: vdsm-jsonrpc-java-1.4.11-1.el7.centos.noarch 
> (ovirt-4.2)13:49:14 11:49:13,951 INFO program:vdsm-jsonrpc-java = 
> 1.4.11-1.el7.centos
>
>
> Looks like  vdsm-jsonrpc-java >= 1.4.12 has not been released yet.
> Piotr please check its status and add it to release configuration file for
> 4.2.3 RC2. You can see an example in https://gerrit.ovirt.org/#/c/90436/
>
> Thanks,
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
> 
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt log analyzer

[Piotr Kliczewski]

On Wed, Apr 4, 2018 at 10:47 AM, Milan Zamazal  wrote:
> Barak Korren  writes:
>
>> Right now, when a test fails in OST - al you get is the traceback from
>> nose of the oVirt API cll you've made. For some tests additional
>> information is provided by having nise collect it from  STDOUT.
>>
>> It could be very useful if we could use some information about the API
>> call that had been made, and use it to extract relevant information
>> about the call from the vdms and engine logs,
>>
>> Can ovirt-log-analyzer be used for that?
>
> Maybe, but not out of the box.  It can parse logs and find some
> relations between Engine and Vdsm logs, so it might be extended to do
> that.  However it's more focused on guess work.  Depending on kind of
> the information to be provided there could be simpler ways to get it.

Is correlation id not enough to find the relations?

> ___
> 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 4.2 ] [ 2018-04-03 ] [006_migrations.prepare_migration_attachments_ipv6]

[Piotr Kliczewski]

Dan,

It looks like it was one of the calls triggered when vdsm was down:

2018-04-03 05:30:16,065-0400 INFO  (mailbox-hsm)
[storage.MailBox.HsmMailMonitor] HSM_MailMonitor sending mail to SPM -
['/usr/bin/dd',
'of=/rhev/data-center/ddb765d2-2137-437d-95f8-c46dbdbc7711/mastersd/dom_md/inbox',
'iflag=fullblock', 'oflag=direct', 'conv=notrunc', 'bs=4096',
'count=1', 'seek=1'] (mailbox:387)
2018-04-03 05:31:22,441-0400 INFO  (MainThread) [vds] (PID: 20548) I
am the actual vdsm 4.20.23-28.gitd11ed44.el7.centos
lago-basic-suite-4-2-host-0 (3.10.0-693.21.1.el7.x86_64) (vdsmd:149)


which failed and caused timeout.

Thanks,
Piotr

On Tue, Apr 3, 2018 at 1:57 PM, Dan Kenigsberg  wrote:

> On Tue, Apr 3, 2018 at 2:07 PM, Barak Korren  wrote:
> > Test failed: [ 006_migrations.prepare_migration_attachments_ipv6 ]
> >
> > Link to suspected patches:
> >
> > (Patch seems unrelated - do we have sporadic communication issues
> > arising in PST?)
> > https://gerrit.ovirt.org/c/89737/1 - vdsm - automation: check-patch:
> > attempt to install vdsm-gluster
> >
> > Link to Job:
> > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/1521/
> >
> > Link to all logs:
> > http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/
> 1521/artifact/exported-artifacts/basic-suit-4.2-el7/
> test_logs/basic-suite-4.2/post-006_migrations.py/
> >
> > Error snippet from log:
> >
> > 
> >
> > Traceback (most recent call last):
> >   File "/usr/lib64/python2.7/unittest/case.py", line 369, in run
> > testMethod()
> >   File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in
> runTest
> > self.test(*self.arg)
> >   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
> > 129, in wrapped_test
> > test()
> >   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
> > 59, in wrapper
> > return func(get_test_prefix(), *args, **kwargs)
> >   File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line
> > 78, in wrapper
> > prefix.virt_env.engine_vm().get_api(api_ver=4), *args, **kwargs
> >   File "/home/jenkins/workspace/ovirt-4.2_change-queue-tester/
> ovirt-system-tests/basic-suite-4.2/test-scenarios/006_migrations.py",
> > line 139, in prepare_migration_attachments_ipv6
> > engine, host_service, MIGRATION_NETWORK, ip_configuration)
> >   File "/home/jenkins/workspace/ovirt-4.2_change-queue-tester/
> ovirt-system-tests/basic-suite-4.2/test_utils/network_utils_v4.py",
> > line 71, in modify_ip_config
> > check_connectivity=True)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/services.py",
> > line 36729, in setup_networks
> > return self._internal_action(action, 'setupnetworks', None,
> > headers, query, wait)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 299, in _internal_action
> > return future.wait() if wait else future
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 55, in wait
> > return self._code(response)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 296, in callback
> > self._check_fault(response)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 132, in _check_fault
> > self._raise_error(response, body)
> >   File "/usr/lib64/python2.7/site-packages/ovirtsdk4/service.py", line
> > 118, in _raise_error
> > raise error
> > Error: Fault reason is "Operation Failed". Fault detail is "[Network
> > error during communication with the Host.]". HTTP response code is
> > 400.
>
> The error occurred sometime in the interval
>
> 09:32:58 [basic-suit] @ Run test: 006_migrations.py:
> 09:33:55 [basic-suit] Error occured, aborting
>
> and indeed
>
> http://jenkins.ovirt.org/job/ovirt-4.2_change-queue-tester/
> 1521/artifact/exported-artifacts/basic-suit-4.2-el7/
> test_logs/basic-suite-4.2/post-006_migrations.py/lago-
> basic-suite-4-2-engine/_var_log/ovirt-engine/engine.log/*view*/
>
> has Engine disconnected from the host at
>
> 2018-04-03 05:33:32,307-04 ERROR
> [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring]
> (EE-ManagedThreadFactory-engineScheduled-Thread-39) [] Unable to
> RefreshCapabilities: VDSNetworkException: VDSGenericException:
> VDSNetworkException: Vds timeout occured
>
> Maybe Piotr can read more into it.
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] vdsm stable branch maitainership

[Piotr Kliczewski]

+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

Re: [ovirt-devel] sslStompReactor just created once, may cause engine failed to connect to new node

[Piotr Kliczewski]

Hello,

One instance of a reactor was done by design. Can you please provide steps
how do you use the code and why do you need to change .truststore?

Thanks,
Piotr

On Wed, Dec 27, 2017 at 2:16 AM, pengyixiang  wrote:

> hello
> If we add a new node, we generate vdsm certs and scp them to node,
> then we add it to .truststore in [1], so that our engine can connect to
> vdsm.
> so If .truststore changed, "getSslStompReactor" still use the old
> .truststore and connect failed. I made a mistake, changed certs is
> .truststore rather than engine.p12
>
>
> [1]
> openssl genrsa \
> -out client/vdsmkey.pem 2048
>
> openssl req \
> -new \
> -out requests/$1.req \
> -key client/vdsmkey.pem \
> -subj "${subject}"
>
> openssl ca \
> -batch \
> -config openssl.conf \
> -extfile cacert2.conf \
> -extensions v3_ca \
> -in requests/$1.req \
> -out certs/$1.cer \
> -keyfile private/ca.pem \
> -subj /O=Linx/CN=$1 \
> -utf8 \
> -days "3650" \
> -startdate "$(date --utc --date "now -1 days"
> +"%y%m%d%H%M%SZ")"
>
> cp ca.pem client/cacert.pem
> cp certs/$1.cer client/vdsmcert.pem
> cp install.sh client
>
> keytool -import -noprompt -trustcacerts -alias $1$(date --utc --date
> "now +1 days" +"%y%m%d%H%M%SZ")$(cat /dev/urandom | head -n 10 | md5sum |
> head -c 10) -keypass mypass -file certs/$1.cer -keystore .truststore
> -storepass mypass
>
>
>
>
>
>
> At 2017-12-26 16:37:33, "Irit Goihman"  wrote:
>
> Hi,
> Can you explain your question?
> Why engine certs are changed?
>
> Thanks,
> Irit
>
> On Mon, Dec 25, 2017 at 3:26 AM, pengyixiang  wrote:
>
>> hello, everyone!
>>  I use ScenarioClient to call vdsm-jsonrpc-client, but I find after
>> my engine connected to one node, I new a node, then the certs(engine.p12)
>> is changed,
>> but engine can not connected to new node, at last, I find the problem in
>> there [1],  and I think rpc's certs to node that is still old, so I try to
>> changed code to [2],
>> then repeat the test way, it works well, the ovirt's engine doesn't meet
>> the trouble and how did you do? client is created like this [3].
>>
>>
>>
>>
>> [1]   https://github.com/oVirt/vdsm-jsonrpc-java/blob/078233e60c24
>> f8b8525b3bf5fb1c5ab9f1c4e0f4/client/src/main/java/org/
>> ovirt/vdsm/jsonrpc/client/reactors/ReactorFactory.java#L76
>>
>> [2]
>>
>> private static Reactor getSslStompReactor(ManagerProvider provider) 
>> throws ClientConnectionException {
>> //if (sslStompReactor != null) {
>> //return sslStompReactor;
>> //}
>> synchronized (ReactorFactory.class) {
>> //if (sslStompReactor != null) {
>> //return sslStompReactor;
>> //}
>> try {
>> sslStompReactor = new 
>> SSLStompReactor(provider.getSSLContext());
>> } catch (IOException | GeneralSecurityException e) {
>> throw new ClientConnectionException(e);
>> }
>> }
>> return sslStompReactor;
>> }
>>
>> [3]
>> public ScenarioClient(String hostname, int port) throws 
>> ClientConnectionException {
>> this.reactor = ReactorFactory.getReactor(ProviderFactory.getProvider(), 
>> ReactorType.STOMP);
>> final ReactorClient client = this.reactor.createClient(hostname, port);
>> client.setClientPolicy(new DefaultStompConnectionPolicy());
>> this.worker = ReactorFactory.getWorker(PARALLELISM);
>> this.jsonClient = this.worker.register(client);
>> this.jsonClient.setRetryPolicy(new DefaultStompClientPolicy());
>> }
>>
>>
>>
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
>
> IRIT GOIHMAN
>
> SOFTWARE ENGINEER
>
> EMEA VIRTUALIZATION R
>
> Red Hat EMEA 
>
> 
> TRIED. TESTED. TRUSTED. 
> @redhatnews    Red Hat
>    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

Re: [ovirt-devel] oVirt 4.2.0 GA status

[Piotr Kliczewski]

On Tue, Dec 19, 2017 at 2:05 PM, Martin Sivak  wrote:
>>> So I think that we still have to fix it somehow.
>>> Are we really sure that nr_retries=2 and _timeout=20 are really the magic 
>>> numbers that works on every conditions?
>>
>>
>> No, it should be tested on HE environment and it depends on your usage.
>
> What does happen when only timeout is specified and the connection
> fails after the command is sent? What are the defaults in that case?

Timeout defines how long we are going to wait for a response. It is
there in the code
for a bit of time already and it is not related to reconnect.

The only control that we expose for reconnect is number of retires.

>
> Martin
>
> On Tue, Dec 19, 2017 at 1:55 PM, Irit Goihman  wrote:
>>
>>
>>
>> On Tue, Dec 19, 2017 at 2:51 PM, Simone Tiraboschi  
>> wrote:
>>>
>>>
>>>
>>> On Tue, Dec 19, 2017 at 12:56 PM, Martin Perina  wrote:

 As Irit mentioned the provided reproduction steps are wrong (misuse of the 
 code) and she posted correct example showing that jsonrpc code works as 
 expected. So Martin/Simone are you using somewhere in HE code the original 
 example that is misusing the client?
>>>
>>>
>>> According to
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1527155#c9
>>> It works in Irit example, at least on that host with that load and timings, 
>>> setting nr_retries=2 and _timeout=20
>>>
>>> While we have _timeout=5 and no custom nr_retries
>>> https://github.com/oVirt/ovirt-hosted-engine-ha/blob/master/ovirt_hosted_engine_ha/lib/util.py#L417
>>>
>>> So I think that we still have to fix it somehow.
>>> Are we really sure that nr_retries=2 and _timeout=20 are really the magic 
>>> numbers that works on every conditions?
>>
>>
>> No, it should be tested on HE environment and it depends on your usage.
>>>
>>>


 Thanks

 Martin


 On Tue, Dec 19, 2017 at 12:53 PM, Oved Ourfali  wrote:
>
> From the latest comment it doesn't seem like a blocker to me.
> Martin S. - your thoughts?
>
> On Tue, Dec 19, 2017 at 1:48 PM, Sandro Bonazzola  
> wrote:
>>
>> We have a proposed blocker for the release:
>> 1527155InfravdsmBindings-APIigoihman@redhat.comNEWjsonrpc reconnect 
>> logic does not work and gets stuckurgentunspecifiedovirt-4.2.004:30:30
>>
>> Please review and either approve the blcoker or postpone to 4.2.1.
>> Thanks,
>>
>>
>> --
>>
>> SANDRO BONAZZOLA
>>
>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>>
>> Red Hat EMEA
>>
>> TRIED. TESTED. TRUSTED.
>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>



 --
 Martin Perina
 Associate Manager, Software Engineering
 Red Hat Czech s.r.o.
>>>
>>>
>>
>>
>>
>> --
>>
>> IRIT GOIHMAN
>>
>> SOFTWARE ENGINEER
>>
>> EMEA VIRTUALIZATION R
>>
>> Red Hat EMEA
>>
>> TRIED. TESTED. TRUSTED.
>> @redhatnews   Red Hat   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

Re: [ovirt-devel] 4.2.0 rc3 postponed to tomorrow

[Piotr Kliczewski]

On Wed, Dec 13, 2017 at 6:08 PM, Sandro Bonazzola 
wrote:

> We still have 2 open blockers:
> 1525375  Storage vdsm
> General eshen...@redhat.com NEW [Engine 4.1] Failed to start VM with
> direct lun on both 4...
>  high unspecified
> ovirt-4.2.0 12:03:41
> 1512534  Integration
> ovirt-hosted-engine-ha General pklic...@redhat.com ASSIGNED SHE
> deployment takes too much time and looks like stuck.
>  urgent urgent
> ovirt-4.2.0 11:30:39
>
>
I am not sure why the BZ was reopened. I described my findings in [1].
During hosted engine setup vdsm ends up in recovery mode which is causing
the setup to fail.
Original issue which was fixed in BZ #1512534 was different and the bug
should not be reopened.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1512534#c39


> Please provide ETA on above blockers
>
> Thanks,
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>
> Red Hat EMEA 
> 
> TRIED. TESTED. TRUSTED. 
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 blockers review

[Piotr Kliczewski]

On Tue, Nov 28, 2017 at 10:26 PM, Martin Perina  wrote:

>
>
> On Tue, Nov 28, 2017 at 11:58 AM, Sandro Bonazzola 
> wrote:
>
>> Hi,
>> I'm waiting for last blockers to be fixed for starting a 4.2.0 RC build.
>> Assignee are in the TO list of this email.
>> So far we are down to 7 bugs: https://bugzilla.redhat.
>> com/buglist.cgi?quicksearch=flag%3Ablocker%2B%20target_miles
>> tone%3Aovirt-4.2.0%20status%3Anew%2Cassigned%2Cpost
>>
>> Please review them and provide an ETA for the fix. If the bug is marked
>> as blocker by mistake, please remove the blocker flag and / or postpone the
>> bug to a later release.
>>
>> Bug ID Product Assignee Status Summary
>> 1516113 cockpit-ovirt phbai...@redhat.com POST Deploy the HostedEngine
>> failed with the default CPU type
>> 1509629 ovirt-engine ah...@redhat.com ASSIGNED Cold merge failed to
>> remove all volumes
>> 1507277 ovirt-engine era...@redhat.com POST [RFE][DR] - Vnic Profiles
>> mapping in VMs register from data storage domain should be supported also
>> for templates
>> 1506677 ovirt-engine dchap...@redhat.com POST Hotplug fail when
>> attaching a disk with cow format on glusterfs
>> 1488338 ovirt-engine mlipc...@redhat.com NEW SPM host is not moving to
>> Non-Operational status when blocking its access to storage domain.
>>
>
> ​I've been able to reproduce that, attached new logs with description to
> the bug. At the moment it doesn't seem to me like something that could be
> fixed​
> ​ easily and quickly​, we will continue investigation tomorrow
>

I checked Martin's logs and it seems like getSpmStatus is getting blocked
for around 1 min and after it engine never receives any responses from vdsm.
I added my findings to the BZ.


>
> ​​
>> 1512534 ovirt-hosted-engine-ha pklic...@redhat.com ASSIGNED SHE
>> deployment takes too much time and looks like stuck.
>>
>
> ​Fix posted and merged​, bug is back at MODIFIED
>
>
>> 1496719 vdsm edwa...@redhat.com POST Port mirroring is not set after VM
>> migration
>>
>> --
>>
>> SANDRO BONAZZOLA
>>
>> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>>
>> Red Hat EMEA 
>> 
>> TRIED. TESTED. TRUSTED. 
>> 
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
> Martin Perina
> Associate Manager, Software Engineering
> Red Hat Czech s.r.o.
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] oVirt 4.2.0 blockers review

[Piotr Kliczewski]

On Tue, Nov 28, 2017 at 11:58 AM, Sandro Bonazzola 
wrote:

> Hi,
> I'm waiting for last blockers to be fixed for starting a 4.2.0 RC build.
> Assignee are in the TO list of this email.
> So far we are down to 7 bugs: https://bugzilla.redhat.
> com/buglist.cgi?quicksearch=flag%3Ablocker%2B%20target_
> milestone%3Aovirt-4.2.0%20status%3Anew%2Cassigned%2Cpost
>
> Please review them and provide an ETA for the fix. If the bug is marked as
> blocker by mistake, please remove the blocker flag and / or postpone the
> bug to a later release.
>
> Bug ID Product Assignee Status Summary
> 1516113 cockpit-ovirt phbai...@redhat.com POST Deploy the HostedEngine
> failed with the default CPU type
> 1509629 ovirt-engine ah...@redhat.com ASSIGNED Cold merge failed to
> remove all volumes
> 1507277 ovirt-engine era...@redhat.com POST [RFE][DR] - Vnic Profiles
> mapping in VMs register from data storage domain should be supported also
> for templates
> 1506677 ovirt-engine dchap...@redhat.com POST Hotplug fail when attaching
> a disk with cow format on glusterfs
> 1488338 ovirt-engine mlipc...@redhat.com NEW SPM host is not moving to
> Non-Operational status when blocking its access to storage domain.
> 1512534 ovirt-hosted-engine-ha pklic...@redhat.com ASSIGNED SHE
> deployment takes too much time and looks like stuck.
>

Patch pushed, verification in progress


> 1496719 vdsm edwa...@redhat.com POST Port mirroring is not set after VM
> migration
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>
> Red Hat EMEA 
> 
> TRIED. TESTED. TRUSTED. 
> 
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [rhev-tech] Correct way to import hooking?

[Piotr Kliczewski]

On Mon, Nov 27, 2017 at 11:56 PM, Germano Veit Michel
<germ...@redhat.com> wrote:
> Hi Piotr and Nir,
>
> Thanks for following up and sorry for sending to the wrong email list.
>
> So is the conclusion that 84638 will be merged and all hooks will just
> "import hooking"?

It is not easy to change it so we need to keep above import. I haven't
seen any disagreement so I
hope that the patch will be merged soon to enable you to write hook tests.

>
> Thanks,
>
>
>
> On Mon, Nov 27, 2017 at 6:32 PM, Piotr Kliczewski
> <piotr.kliczew...@gmail.com> wrote:
>>
>> On Sat, Nov 25, 2017 at 1:56 AM, Nir Soffer <nsof...@redhat.com> wrote:
>> > On Fri, Nov 24, 2017 at 5:34 PM Piotr Kliczewski
>> > <piotr.kliczew...@gmail.com> wrote:
>> >>
>> >> On Fri, Nov 24, 2017 at 4:00 PM, Piotr Kliczewski
>> >> <piotr.kliczew...@gmail.com> wrote:
>> >> > On Fri, Nov 24, 2017 at 2:20 PM, Nir Soffer <nsof...@redhat.com>
>> >> > wrote:
>> >> >> Adding devel@ovirt, the proper mailing list
>> >> >>
>> >> >> בתאריך יום ו׳, 24 בנוב׳ 2017, 7:42, מאת Germano Veit Michel
>> >> >> ‏<germ...@redhat.com>:
>> >> >>>
>> >> >>> Hi,
>> >> >>>
>> >> >>> I'm trying to write a test for a hook. The test will fail if the
>> >> >>> hook
>> >> >>> does
>> >> >>> "import hooking", which seems to be the norm for vdsm hooks.
>> >> >>>
>> >> >>> [vdsm_hooks]$ grep -rn "import hooking" | wc -l
>> >> >>> 55
>> >> >>>
>> >> >>> Not sure if I'm doing something wrong, but it looks like I would
>> >> >>> need
>> >> >>> vdsm
>> >> >>> installed on my development machine in order for this import to
>> >> >>> work.
>> >> >>>
>> >> >>>
>> >> >>> ==
>> >> >>> ERROR: test suite for > >> >>> 'virttests.boot_hostdev_test.BootHostdevHookTests'>
>> >> >>>
>> >> >>> --
>> >> >>> 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
>> >> >>>
>> >> >>>
>> >> >>> "/home/gveitmic/Source/upstream/vdsm/tests/virttests/boot_hostdev_test.py",
>> >> >>> line 127, in setUpClass
>> >> >>> import before_vm_start as boot_hostdev_hook
>> >> >>>   File "../vdsm_hooks/boot_hostdev/before_vm_start.py", line 24, in
>> >> >>> 
>> >> >>> import hooking
>> >> >>> ImportError: No module named hooking
>> >
>> >
>> > This is expected, hooking is not install in the pyhton path by default.
>> >
>> > All the hooks are using wrong import. Vdsm is "fixing" the bad
>> > import by modifying the python path.
>> >
>> >>
>> >> >>>
>> >> >>> I can make it go away by using this in my hook:
>> >> >>>
>> >> >>> from vdsm.hook import hooking
>> >
>> >
>> > This is correct import - I would use this.
>> >
>> >>
>> >> >>>
>> >> >>> Then the test succeeds fine. But then I see all hooks use "import
&

Re: [ovirt-devel] [rhev-tech] Correct way to import hooking?

[Piotr Kliczewski]

On Sat, Nov 25, 2017 at 1:56 AM, Nir Soffer <nsof...@redhat.com> wrote:
> On Fri, Nov 24, 2017 at 5:34 PM Piotr Kliczewski
> <piotr.kliczew...@gmail.com> wrote:
>>
>> On Fri, Nov 24, 2017 at 4:00 PM, Piotr Kliczewski
>> <piotr.kliczew...@gmail.com> wrote:
>> > On Fri, Nov 24, 2017 at 2:20 PM, Nir Soffer <nsof...@redhat.com> wrote:
>> >> Adding devel@ovirt, the proper mailing list
>> >>
>> >> בתאריך יום ו׳, 24 בנוב׳ 2017, 7:42, מאת Germano Veit Michel
>> >> ‏<germ...@redhat.com>:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I'm trying to write a test for a hook. The test will fail if the hook
>> >>> does
>> >>> "import hooking", which seems to be the norm for vdsm hooks.
>> >>>
>> >>> [vdsm_hooks]$ grep -rn "import hooking" | wc -l
>> >>> 55
>> >>>
>> >>> Not sure if I'm doing something wrong, but it looks like I would need
>> >>> vdsm
>> >>> installed on my development machine in order for this import to work.
>> >>>
>> >>> ==
>> >>> ERROR: test suite for > >>> 'virttests.boot_hostdev_test.BootHostdevHookTests'>
>> >>> --
>> >>> 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
>> >>>
>> >>> "/home/gveitmic/Source/upstream/vdsm/tests/virttests/boot_hostdev_test.py",
>> >>> line 127, in setUpClass
>> >>> import before_vm_start as boot_hostdev_hook
>> >>>   File "../vdsm_hooks/boot_hostdev/before_vm_start.py", line 24, in
>> >>> 
>> >>> import hooking
>> >>> ImportError: No module named hooking
>
>
> This is expected, hooking is not install in the pyhton path by default.
>
> All the hooks are using wrong import. Vdsm is "fixing" the bad
> import by modifying the python path.
>
>>
>> >>>
>> >>> I can make it go away by using this in my hook:
>> >>>
>> >>> from vdsm.hook import hooking
>
>
> This is correct import - I would use this.
>
>>
>> >>>
>> >>> Then the test succeeds fine. But then I see all hooks use "import
>> >>> hooking"
>> >>> instead of "from vdsm.hook import hooking".
>> >>>
>> >>> [vdsm_hooks]$ grep -rn "from vdsm.hook import hooking" | wc -l
>> >>> 0
>> >>>
>> >>> Am I doing something wrong? Can someone put a light here? What is the
>> >>> correct way to do this import?
>> >
>> > Our approach for it is to modify PYTHONPATH [1] where we add vdsm.hook.
>> > It looks like we do not have similar update in [2] - script which run
>> > the tests.
>> >
>> > I will push a patch to fix it.
>>
>> https://gerrit.ovirt.org/#/c/84638/
>>
>> Please check whether it would work for you now.
>
>
> This can be handy for testing legacy hooks, but I think we should
> fix the imports instead, so no manipulation of python path is needed.
>

I agree that the path is not perfect way of doing it. I would love to fix it but
please note that people use `import hooking` in their own custom hooks
and we are unable to change them. This means that we won't be able to
fix it easily if ever. Because of that I am not sure whether it is good idea to
introduce different way of importing the module.

Till now we haven't had hook tests so the module was not available on the path.

>>
>>
>> >
>> > [1] https://github.com/oVirt/vdsm/blob/master/lib/vdsm/hooks.py#L98
>> > [2]
>> > https://github.com/oVirt/vdsm/blob/master/tests/run_tests_local.sh.in#L21
>> >
>> >>>
>> >>> Thanks,
>> >>> Germano
>> >>
>> >>
>> >> ___
>> >> 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] [rhev-tech] Correct way to import hooking?

[Piotr Kliczewski]

On Fri, Nov 24, 2017 at 4:00 PM, Piotr Kliczewski
<piotr.kliczew...@gmail.com> wrote:
> On Fri, Nov 24, 2017 at 2:20 PM, Nir Soffer <nsof...@redhat.com> wrote:
>> Adding devel@ovirt, the proper mailing list
>>
>> בתאריך יום ו׳, 24 בנוב׳ 2017, 7:42, מאת Germano Veit Michel
>> ‏<germ...@redhat.com>:
>>>
>>> Hi,
>>>
>>> I'm trying to write a test for a hook. The test will fail if the hook does
>>> "import hooking", which seems to be the norm for vdsm hooks.
>>>
>>> [vdsm_hooks]$ grep -rn "import hooking" | wc -l
>>> 55
>>>
>>> Not sure if I'm doing something wrong, but it looks like I would need vdsm
>>> installed on my development machine in order for this import to work.
>>>
>>> ==
>>> ERROR: test suite for >> 'virttests.boot_hostdev_test.BootHostdevHookTests'>
>>> --
>>> 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
>>> "/home/gveitmic/Source/upstream/vdsm/tests/virttests/boot_hostdev_test.py",
>>> line 127, in setUpClass
>>> import before_vm_start as boot_hostdev_hook
>>>   File "../vdsm_hooks/boot_hostdev/before_vm_start.py", line 24, in
>>> 
>>> import hooking
>>> ImportError: No module named hooking
>>>
>>> I can make it go away by using this in my hook:
>>>
>>> from vdsm.hook import hooking
>>>
>>> Then the test succeeds fine. But then I see all hooks use "import hooking"
>>> instead of "from vdsm.hook import hooking".
>>>
>>> [vdsm_hooks]$ grep -rn "from vdsm.hook import hooking" | wc -l
>>> 0
>>>
>>> Am I doing something wrong? Can someone put a light here? What is the
>>> correct way to do this import?
>
> Our approach for it is to modify PYTHONPATH [1] where we add vdsm.hook.
> It looks like we do not have similar update in [2] - script which run the 
> tests.
>
> I will push a patch to fix it.

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

Please check whether it would work for you now.

>
> [1] https://github.com/oVirt/vdsm/blob/master/lib/vdsm/hooks.py#L98
> [2] https://github.com/oVirt/vdsm/blob/master/tests/run_tests_local.sh.in#L21
>
>>>
>>> Thanks,
>>> Germano
>>
>>
>> ___
>> 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] [rhev-tech] Correct way to import hooking?

[Piotr Kliczewski]

On Fri, Nov 24, 2017 at 2:20 PM, Nir Soffer  wrote:
> Adding devel@ovirt, the proper mailing list
>
> בתאריך יום ו׳, 24 בנוב׳ 2017, 7:42, מאת Germano Veit Michel
> ‏:
>>
>> Hi,
>>
>> I'm trying to write a test for a hook. The test will fail if the hook does
>> "import hooking", which seems to be the norm for vdsm hooks.
>>
>> [vdsm_hooks]$ grep -rn "import hooking" | wc -l
>> 55
>>
>> Not sure if I'm doing something wrong, but it looks like I would need vdsm
>> installed on my development machine in order for this import to work.
>>
>> ==
>> ERROR: test suite for > 'virttests.boot_hostdev_test.BootHostdevHookTests'>
>> --
>> 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
>> "/home/gveitmic/Source/upstream/vdsm/tests/virttests/boot_hostdev_test.py",
>> line 127, in setUpClass
>> import before_vm_start as boot_hostdev_hook
>>   File "../vdsm_hooks/boot_hostdev/before_vm_start.py", line 24, in
>> 
>> import hooking
>> ImportError: No module named hooking
>>
>> I can make it go away by using this in my hook:
>>
>> from vdsm.hook import hooking
>>
>> Then the test succeeds fine. But then I see all hooks use "import hooking"
>> instead of "from vdsm.hook import hooking".
>>
>> [vdsm_hooks]$ grep -rn "from vdsm.hook import hooking" | wc -l
>> 0
>>
>> Am I doing something wrong? Can someone put a light here? What is the
>> correct way to do this import?

Our approach for it is to modify PYTHONPATH [1] where we add vdsm.hook.
It looks like we do not have similar update in [2] - script which run the tests.

I will push a patch to fix it.

[1] https://github.com/oVirt/vdsm/blob/master/lib/vdsm/hooks.py#L98
[2] https://github.com/oVirt/vdsm/blob/master/tests/run_tests_local.sh.in#L21

>>
>> Thanks,
>> Germano
>
>
> ___
> 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

[Piotr Kliczewski]

On Thu, Nov 23, 2017 at 8:52 AM, Barak Korren <bkor...@redhat.com> wrote:

> On 23 November 2017 at 09:47, Piotr Kliczewski <pklic...@redhat.com>
> wrote:
>
> >>
> >> Not sure what this failure means, is it something I need to fix in the
> >> infra?
> >
> >
> > It is not for infra. I saw it few times as well.
> >
>
> So, should I just rerun?
>
>
yes, please do


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

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

[Piotr Kliczewski]

Nir, Thank you for finalizing the effort.

On Thu, Nov 23, 2017 at 8:30 AM, Barak Korren  wrote:

> On 23 November 2017 at 09:27, Francesco Romani  wrote:
> >
> > On 11/23/2017 08:25 AM, Barak Korren wrote:
> >
> >
> > The package exists:
> > http://resources.ovirt.org/repos/ovirt/tested/master/rpm/
> fc27/noarch/ovirt-imageio-common-1.2.0-0.201711212128.
> git9926984.fc27.noarch.rpm
> >
> > repoquery is happy:
> > $ repoquery
> > --repofrompath=r,http://resources.ovirt.org/repos/
> ovirt/tested/master/rpm/fc27
> > --repoid=r list ovirt-imageio-common
> > ovirt-imageio-common-0:1.2.0-0.201711212128.git9926984.fc27.noarch
> >
> > Maybe mock caching issue?
> >
> > 00:00:28.127 Using chroot cache =
> > /var/cache/mock/fedora-27-x86_64-a9934b467f29c7317f7dd8f205d66ddd
> > 00:00:28.127 Using chroot dir =
> > /var/lib/mock/fedora-27-x86_64-a9934b467f29c7317f7dd8f205d66ddd-7425
> >
> >
> > No. This just tells you where the cache would be, not if its actually
> > there already.
> > But yeah, this run actually did use a cached chroot:
> >
> >  00:00:28.767 Start: unpacking root cache
> >  00:01:01.624 Finish: unpacking root cache
> >
> > I cleaned it from the node and retriggerd, lets see what happens now:
> >
> >
> > http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-
> x86_64/85/console
> >
> > Failed again:
> >
> > 00:11:56.063
> > 
> 
> -
> > 00:11:56.064 TOTAL
> > 49960
> > 2528049%
> > 00:11:56.064
> > --
> > 00:11:56.065 Ran 2547 tests in 307.236s
> > 00:11:56.065
> > 00:11:56.065 FAILED (SKIP=78, failures=4)
> > 00:11:56.065 make[1]: *** [Makefile:1118: check] Error 1
> > 00:11:56.066 make[1]: Leaving directory
> > '/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_64/vdsm/tests'
> > 00:11:56.066 ERROR: InvocationError: '/usr/bin/make -C tests check'
> > 00:11:56.067 storage-py27 create:
> > /home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_
> 64/vdsm/.tox/storage-py27
> > 00:11:59.803 storage-py27 installdeps: pytest==3.1.2, nose==1.3.7
> >
> > 
> >
> > 00:14:06.238 ___ summary
> > 
> > 00:14:06.238 ERROR:   tests: commands failed
> > 00:14:06.238   storage-py27: commands succeeded
> > 00:14:06.238 SKIPPED:  storage-py35: InterpreterNotFound: python3.5
> > 00:14:06.239   storage-py36: commands succeeded
> > 00:14:06.239   lib-py27: commands succeeded
> > 00:14:06.264 make: *** [Makefile:1019: tests] Error 1
> > 00:14:06.270 + collect-logs
> > 00:14:06.270 + cp /var/log/vdsm_tests.log
> > /home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_
> 64/vdsm/exported-artifacts/
> > 00:14:06.280 Took 488 seconds
> >
> >
> > I can't really tell why this failed, also did we use to have the
> > results exported to XUINT?
> >
> >
> > It seems it failed because:
> >
> > 07:12:24
> > 07:12:24
> > ==
> > 07:12:24 FAIL: test_multiple_vlans (network.tc_test.
> TestConfigureOutbound)
> > 07:12:24
> > --
> > 07:12:24 Traceback (most recent call last):
> > 07:12:24   File "/usr/lib/python2.7/site-packages/mock/mock.py", line
> 1305,
> > in patched
> > 07:12:24 return func(*args, **keywargs)
> > 07:12:24   File
> > "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_
> 64/vdsm/tests/network/tc_test.py",
> > line 459, in test_multiple_vlans
> > 07:12:24 self._analyse_qos_and_general_assertions()
> > 07:12:24   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
> > 07:12:24 tc_filters.tagged_filters)
> > 07:12:24   File
> > "/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_
> 64/vdsm/tests/network/tc_test.py",
> > line 579, in _assertions_on_filters
> > 07:12:24 self.assertEqual(len(untagged_filters), 1)
> > 07:12:24 AssertionError: 0 != 1
> > 07:12:24  >> begin captured logging <<
> > 
> >
>
> Not sure what this failure means, is it something I need to fix in the
> infra?
>

It is not for infra. I saw it few times as well.


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

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

[Piotr Kliczewski]

On Mon, Nov 20, 2017 at 6:34 PM, Barak Korren <bkor...@redhat.com> wrote:
> On 20 November 2017 at 19:16, Piotr Kliczewski <pklic...@redhat.com> wrote:
>>
>>
>> On Mon, Nov 20, 2017 at 5:00 PM, Piotr Kliczewski
>> <piotr.kliczew...@gmail.com> wrote:
>>>
>>> On Mon, Nov 20, 2017 at 4:57 PM, Barak Korren <bkor...@redhat.com> wrote:
>>> > On 20 November 2017 at 17:09, Piotr Kliczewski <pklic...@redhat.com>
>>> > wrote:
>>> >>
>>> >> @Barak can we fix it?
>>> >>
>>> >
>>> > Why are you trying to use lago repos in check-patch?
>>> > There is no cf27/rawhide build of Lago yet, maybe just remove them
>>> > from the appropriate *.repo files?
>>> >
>>>
>>> repo file reuse, will fix
>>>
>>
>> I removed repos not available on fc27/fcraw and I got failures [1][2]:
>>
>> ImportError: No module named ovirt_imageio_common
>>
>> I see that [3] repo is not available for fcraw. I see that [4], [5] and [6]
>> are not available for both.
>
> [3] should become available as soon as any project builds successfully
> for FCRAW, not sure which packages you actually need from there
> though.

Does it mean that if imageio was built successfully it will be created?

> [4] should not be needed, what are you still using from there?
> not sure what is it you need from [5] either - probably just 'repoman'
> for lago [6], so not needed by things other then check-merged.
>

All repos were there as used by fc26. If there is not needed to use
them we should cleanup.

>
>>
>> It seems that we are not ready for enabling the jobs for both os versions.
>> Maybe we should consider revert of [7].
>>
>> Thanks,
>> Piotr
>>
>> [1] http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/48/
>> [2] http://jenkins.ovirt.org/job/vdsm_master_check-patch-fcraw-x86_64/49/
>> [3] tested,http://resources.ovirt.org/repos/ovirt/tested/master/rpm/$distro
>> [4]
>> ovirt-snapshot-static,http://resources.ovirt.org/pub/ovirt-master-snapshot-static/rpm/$distro
>> [5] ovirt-ci-tools,http://resources.ovirt.org/repos/ci-tools/$distro
>> [6] lago,http://resources.ovirt.org/repos/lago/stable/0.0/rpm/$distro
>> [7] https://gerrit.ovirt.org/#/c/84370/
>>
>>
>
>
>
> --
> 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

[Piotr Kliczewski]

On Mon, Nov 20, 2017 at 5:00 PM, Piotr Kliczewski <
piotr.kliczew...@gmail.com> wrote:

> On Mon, Nov 20, 2017 at 4:57 PM, Barak Korren <bkor...@redhat.com> wrote:
> > On 20 November 2017 at 17:09, Piotr Kliczewski <pklic...@redhat.com>
> wrote:
> >>
> >> @Barak can we fix it?
> >>
> >
> > Why are you trying to use lago repos in check-patch?
> > There is no cf27/rawhide build of Lago yet, maybe just remove them
> > from the appropriate *.repo files?
> >
>
> repo file reuse, will fix
>
>
I removed repos not available on fc27/fcraw and I got failures [1][2]:

ImportError: No module named ovirt_imageio_common

I see that [3] repo is not available for fcraw. I see that [4], [5]
and [6] are not available for both.

It seems that we are not ready for enabling the jobs for both os
versions. Maybe we should consider revert of [7].

Thanks,
Piotr

[1] http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/48/
[2] http://jenkins.ovirt.org/job/vdsm_master_check-patch-fcraw-x86_64/49/
[3] tested,http://resources.ovirt.org/repos/ovirt/tested/master/rpm/$distro
[4] 
ovirt-snapshot-static,http://resources.ovirt.org/pub/ovirt-master-snapshot-static/rpm/$distro
[5] ovirt-ci-tools,http://resources.ovirt.org/repos/ci-tools/$distro
[6] lago,http://resources.ovirt.org/repos/lago/stable/0.0/rpm/$distro
[7] https://gerrit.ovirt.org/#/c/84370/
___
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

[Piotr Kliczewski]

On Mon, Nov 20, 2017 at 4:57 PM, Barak Korren <bkor...@redhat.com> wrote:
> On 20 November 2017 at 17:09, Piotr Kliczewski <pklic...@redhat.com> wrote:
>> I see a failure for [1]
>>
>> with:
>> http://resources.ovirt.org/repos/lago/stable/0.0/rpm/fcraw/repodata/repomd.xml:
>> [Errno 14] HTTP Error 404 - Not Found
>>
>> and for [2]
>>
>> with
>> http://resources.ovirt.org/repos/lago/stable/0.0/rpm/fc27/repodata/repomd.xml:
>> [Errno 14] HTTP Error 404 - Not Found
>>
>> @Barak can we fix it?
>>
>
> Why are you trying to use lago repos in check-patch?
> There is no cf27/rawhide build of Lago yet, maybe just remove them
> from the appropriate *.repo files?
>

repo file reuse, will fix

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

[Piotr Kliczewski]

I see a failure for [1]

with:
http://resources.ovirt.org/repos/lago/stable/0.0/rpm/fcraw/repodata/repomd.xml:
[Errno 14] HTTP Error 404 - Not Found

and for [2]

with
http://resources.ovirt.org/repos/lago/stable/0.0/rpm/fc27/repodata/repomd.xml:
[Errno 14] HTTP Error 404 - Not Found

@Barak can we fix it?

Thanks,
Piotr

[1] http://jenkins.ovirt.org/job/vdsm_master_check-patch-fcraw-x86_64/20/
[2] http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/20/

On Mon, Nov 20, 2017 at 4:01 PM, Dan Kenigsberg <dan...@redhat.com> wrote:

> On Mon, Nov 20, 2017 at 4:57 PM, Barak Korren <bkor...@redhat.com> wrote:
> > On 20 November 2017 at 16:47, Dan Kenigsberg <dan...@redhat.com> wrote:
> >> On Mon, Nov 20, 2017 at 1:16 PM, Piotr Kliczewski <pklic...@redhat.com>
> wrote:
> >>>
> >>>
> >>> On Sat, Nov 18, 2017 at 10:20 AM, Piotr Kliczewski <
> pklic...@redhat.com>
> >>> wrote:
> >>>>
> >>>> Yes, I can do that.
> >>>
> >>>
> >>> Here are the patches:
> >>> https://gerrit.ovirt.org/84368
> >>> https://gerrit.ovirt.org/84370
> >>
> >> Note for future: the project should be ready (84368 merged) before CI
> >> is requested to use it (84370).
> >> The patches where merged in reverse order, so we currently have broken
> >> CI for Vdsm until 84368 is merged.
> >
> > You can actually just rebase failing patches on top of 84368 to get
> > them to pass properly.
>
> and that is what I personally did; but that's "Toshba" is they say in
> the Yeshiva. master is currently broken because we merged the patches
> in the wrong order.
>
___
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

[Piotr Kliczewski]

On Sat, Nov 18, 2017 at 10:20 AM, Piotr Kliczewski <pklic...@redhat.com>
wrote:

> Yes, I can do that.
>

Here are the patches:
https://gerrit.ovirt.org/84368
https://gerrit.ovirt.org/84370


>
> 17.11.2017 21:27 "Nir Soffer" <nsof...@redhat.com> napisał(a):
>
>>
>>
>> On Mon, Oct 16, 2017 at 8:36 AM Dan Kenigsberg <dan...@redhat.com> wrote:
>>
>>> On Mon, Oct 16, 2017 at 8:25 AM, Barak Korren <bkor...@redhat.com>
>>> wrote:
>>> >
>>> >
>>> > On 15 October 2017 at 19:43, Dan Kenigsberg <dan...@redhat.com> wrote:
>>> >>
>>> >>
>>> >> Down sides are waste of resources, slower CI responsiveness, and more
>>> >> importantly: rawhide fragility may cause more unrelated failures.
>>> >
>>> >
>>> > I don't think it will be that much of a resource issue. Our non-peak
>>> slave
>>> > utilization is pretty low. And you can just remove some of the older
>>> Fedora
>>> > versions.
>>> >
>>> > I suggest not to make too many premature assumptions. If rawhide
>>> testing is
>>> > useful for you, just add it and see how it behaves over time...
>>> >
>>> >> Nir, with your experience - does it worth it?
>>> >>
>>> >> How about having "rawhide" as non-voting?
>>> >
>>> >
>>> > You can accomplish that easily - just add a 'check-patch.sh.fcraw'
>>> script
>>> > that would source the normal 'check-patch.sh' and throw away the
>>> process
>>> > return value.
>>>
>>> This would eliminate the only benefit I see in having rawhide at all:
>>> I'd like to see the rawhide job in RED if it is currently broken, so I
>>> can look deeper to see why. If it's always green, it's useless to me.
>>> However, if it is often red due to temporary unrelated changes, I
>>> would not like it to block fixes.
>>>
>>> But as you say, we can try it out and check the signal/noise ratio.
>>>
>>
>> I sent patches for ovirt-imageio, we need similar patches for vdsm.
>> https://gerrit.ovirt.org/84309/
>> https://gerrit.ovirt.org/84308/
>>
>> Piotr, can you handle this for vdsm?
>>
>> Nir
>>
>>
>
___
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

[Piotr Kliczewski]

Yes, I can do that.

17.11.2017 21:27 "Nir Soffer"  napisał(a):

>
>
> On Mon, Oct 16, 2017 at 8:36 AM Dan Kenigsberg  wrote:
>
>> On Mon, Oct 16, 2017 at 8:25 AM, Barak Korren  wrote:
>> >
>> >
>> > On 15 October 2017 at 19:43, Dan Kenigsberg  wrote:
>> >>
>> >>
>> >> Down sides are waste of resources, slower CI responsiveness, and more
>> >> importantly: rawhide fragility may cause more unrelated failures.
>> >
>> >
>> > I don't think it will be that much of a resource issue. Our non-peak
>> slave
>> > utilization is pretty low. And you can just remove some of the older
>> Fedora
>> > versions.
>> >
>> > I suggest not to make too many premature assumptions. If rawhide
>> testing is
>> > useful for you, just add it and see how it behaves over time...
>> >
>> >> Nir, with your experience - does it worth it?
>> >>
>> >> How about having "rawhide" as non-voting?
>> >
>> >
>> > You can accomplish that easily - just add a 'check-patch.sh.fcraw'
>> script
>> > that would source the normal 'check-patch.sh' and throw away the process
>> > return value.
>>
>> This would eliminate the only benefit I see in having rawhide at all:
>> I'd like to see the rawhide job in RED if it is currently broken, so I
>> can look deeper to see why. If it's always green, it's useless to me.
>> However, if it is often red due to temporary unrelated changes, I
>> would not like it to block fixes.
>>
>> But as you say, we can try it out and check the signal/noise ratio.
>>
>
> I sent patches for ovirt-imageio, we need similar patches for vdsm.
> https://gerrit.ovirt.org/84309/
> https://gerrit.ovirt.org/84308/
>
> Piotr, can you handle this for vdsm?
>
> Nir
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt 4.1 ] [ 09-11-2017 ] [ 001_upgrade_engine.test_initialize_engine ]

[Piotr Kliczewski]

On Thu, Nov 9, 2017 at 2:49 PM, Dafna Ron  wrote:

> Hi,
>
> We had a failure in installing engine with a dependency error between
> ovirt-engine-backend and vdsm-jsonrpc-java
>
> Please note that we have other issues which are not related to this patch
> so it might be hard to find this issue.
>
> I also added the lago log where you can find the package dependency error.
>
> *Link to suspected patches: https://gerrit.ovirt.org/#/c/82995/
> *
>
>
> * Link to
> Job:http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1291
>  *
>
> http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/
> 1291/artifact/exported-artifacts/upgrade-from-
> prevrelease-suit-4.1-el7/test_logs/upgrade-from-prevrelease-
> suite-4.1/post-001_upgrade_engine.py/lago_logs/lago.log
>
>
>
I see that [1] is green. What happened since it was built so jsonrpc is not
available?

[1] http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1290/


> *Link to all logs:
> http://jenkins.ovirt.org/job/ovirt-4.1_change-queue-tester/1291/artifact
> *
>
> * (Relevant) error snippet from the log:  *
>
>
> [ INFO  ] Checking for an update for Setup...
> [ ERROR ] Yum 
> [u'ovirt-engine-backend-4.1.7.7-0.0.master.20171109084643.gitcd8d74c.el7.centos.noarch
>  requires vdsm-jsonrpc-java >= 1.3.14']
> [ INFO  ] Yum Performing yum transaction rollback
> [ ERROR ] Failed to execute stage 'Environment customization': 
> [u'ovirt-engine-backend-4.1.7.7-0.0.master.20171109084643.gitcd8d74c.el7.centos.noarch
>  requires vdsm-jsonrpc-java >= 1.3.14']
> [ INFO  ] Stage: Clean up
>   Log file is located at 
> /var/log/ovirt-engine/setup/ovirt-engine-setup-20171109042111-tpncix.log
> [ INFO  ] Generating answer file 
> '/var/lib/ovirt-engine/setup/answers/20171109042115-setup.conf'
> [ INFO  ] Stage: Pre-termination
> [ INFO  ] Stage: Termination
> [ ERROR ] Execution of setup failed
>
>
> **
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Additional patches in vdsm - post mortem

[Piotr Kliczewski]

On Tue, Oct 10, 2017 at 4:47 PM, Dan Kenigsberg <dan...@redhat.com> wrote:
> On Mon, Oct 9, 2017 at 11:12 AM, Piotr Kliczewski
> <piotr.kliczew...@gmail.com> wrote:
>> All,
>>
>> Recently you could notice few patches being merged and later reverted.
>> I would like to say what happened. Sometime ago I pushed a tag to
>> vdsm-jsonrpc-java and later reused that command from my history to
>> push 6 patches [1][2][3][4][5][6] to vdsm for a review. I did not
>> notice that I pushed for `heads/master` instead of `for/master` this
>> caused to bypass gerrit and the patches were merged. When I noticed
>> what happened I pushed [7] to revert it. I hope no-one was affected.
>>
>> Thanks,
>> Piotr
>
> Thanks for your report, Piotr.
>
> I believe that [7] should have been sent properly, via gerrit, and not
> by direct git merge. Unless we close git access, errors would happen.
> But when you realize you've made a mistake, better fix via gerrit.

You are right. I should have done it via gerrit. My only justification
is that I wanted to
reduce potential issues that people could have.

>
> In particular, I think [7] has mistakes; it is not clear to me how you
> have produced it.

I did git revert --no-commit for all the patches. Unfortunately my
source tree was not
clear.

>
> fc1174c91~ is the last commit before the mess occurred, right? da18b865 is 
> [7].
> But
> $ git diff --name-only fc1174c91~..da18b865|cat
> .cache/v/cache/lastfailed
> init/systemd/systemd-vdsmd
>
> is not empty. It introduces two files with no good reason.

I noticed this as well and pushed [8] which removes those files.

[8] https://gerrit.ovirt.org/#/c/82648/

>
>
>
>>
>> [1] 
>> https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=fc1174c91f68ba389df5ef7269d54a942da93f8f
>> [2] 
>> https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=4d2f50014a96f9f98d811d0818743dc36ab82732
>> [3] 
>> https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=8937d12ac55cc9fba103306d656fea44c1ae0a2b
>> [4] 
>> https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=27912da968d24b26b577a6a944810b331e51f6ff
>> [5] 
>> https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=b10d699e884fd6e73ff686e23433d14fbdc2df6e
>> [6] 
>> https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=d668f11a8390397de96c91ac2ab8860186d2cfa2
>> [7] 
>> https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=da18b8651a0c32792d507f99e19f9d4aed8be060
>> ___
>> 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] Additional patches in vdsm - post mortem

[Piotr Kliczewski]

All,

Recently you could notice few patches being merged and later reverted.
I would like to say what happened. Sometime ago I pushed a tag to
vdsm-jsonrpc-java and later reused that command from my history to
push 6 patches [1][2][3][4][5][6] to vdsm for a review. I did not
notice that I pushed for `heads/master` instead of `for/master` this
caused to bypass gerrit and the patches were merged. When I noticed
what happened I pushed [7] to revert it. I hope no-one was affected.

Thanks,
Piotr

[1] 
https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=fc1174c91f68ba389df5ef7269d54a942da93f8f
[2] 
https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=4d2f50014a96f9f98d811d0818743dc36ab82732
[3] 
https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=8937d12ac55cc9fba103306d656fea44c1ae0a2b
[4] 
https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=27912da968d24b26b577a6a944810b331e51f6ff
[5] 
https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=b10d699e884fd6e73ff686e23433d14fbdc2df6e
[6] 
https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=d668f11a8390397de96c91ac2ab8860186d2cfa2
[7] 
https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=commit;h=da18b8651a0c32792d507f99e19f9d4aed8be060
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [devel] ovirt-engine NFE on master

[Piotr Kliczewski]

On Thu, Sep 7, 2017 at 11:32 AM, Milan Zamazal <mzama...@redhat.com> wrote:
> Piotr Kliczewski <piotr.kliczew...@gmail.com> writes:
>
>> There few ways I could get there:
>> 1. Testing some code and creating vdsm and later dropping db and
>> reinstalling the host with "new db"
>> 2. Vms provisioned manually.
>
> I.e. outside oVirt?  If they are external VMs then it explains why you
> get the tracebacks and we have a fix posted
> (https://gerrit.ovirt.org/81529).  I was worried that the tracebacks
> could be caused by oVirt VMs.

Not in this case.

>
>> At this time it seems to be option #2 and I see:
>>
>> [root@f20 ~]# virsh -r list --all
>>  IdName   State
>> 
>>  - centos7shut off
>>  - rhel7.0-devshut off
>>
>> which are machines where I test el7 compatibility of my changes (I use
>> fedora25 on bare metal).
>>
>> I see the failure every time I run the engine now since I sent the
>> email to this thread. It started
>> to occur recently event though I have those vms there for really long time.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [devel] ovirt-engine NFE on master

[Piotr Kliczewski]

On Wed, Sep 6, 2017 at 6:35 PM, Milan Zamazal <mzama...@redhat.com> wrote:
> Piotr Kliczewski <piotr.kliczew...@gmail.com> writes:
>
>> I pulled the latest engine master [1] and I see following exception
>> below. Is it known issue?
>
> Piotr, what's the libvirt version on your host?  Is the cluster version
> 4.2?  And did you migrate some VM?

I am using:

Name: libvirt
Arch: x86_64
Epoch   : 0
Version : 3.2.1
Release : 3.fc25

My cluster version is: 4.2

I haven't performed any migrations in this environment.

>
> Thanks,
> Milan
>
>> [1] Based on 34f4d69117d916e52a7b2d5032d64b8d1185448c
>>
>> 2017-09-01 13:35:38,829+02 ERROR
>> [org.ovirt.engine.core.bll.AddUnmanagedVmsCommand]
>> (DefaultQuartzScheduler10) [353095e7] Command
>> 'org.ovirt.engine.core.bll.AddUnmanagedVmsCommand' failed: null
>> 2017-09-01 13:35:38,829+02 ERROR
>> [org.ovirt.engine.core.bll.AddUnmanagedVmsCommand]
>> (DefaultQuartzScheduler10) [353095e7] Exception:
>> java.lang.NumberFormatException: null
>> at java.lang.Integer.parseInt(Integer.java:542) [rt.jar:1.8.0_141]
>> at java.lang.Integer.parseInt(Integer.java:615) [rt.jar:1.8.0_141]
>> at
>> org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerObjectsBuilder.parseIntVdsProperty(VdsBrokerObjectsBuilder.java:775)
>> [vdsbroker.jar:]
>> at 
>> org.ovirt.engine.core.bll.AddUnmanagedVmsCommand.convertVm(AddUnmanagedVmsCommand.java:119)
>> [bll.jar:]
>> at 
>> org.ovirt.engine.core.bll.AddUnmanagedVmsCommand.executeCommand(AddUnmanagedVmsCommand.java:96)
>> [bll.jar:]
>> at 
>> org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1202)
>> [bll.jar:]
>> at 
>> org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1342)
>> [bll.jar:]
>> at 
>> org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1984)
>> [bll.jar:]
>> at 
>> org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164)
>> [utils.jar:]
>> at 
>> org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103)
>> [utils.jar:]
>> ___
>> 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] failed to run JsonRpcIntegrationTest independecy

[Piotr Kliczewski]

Tests are not meant to talk to vdsm. You can try this [1]. I wrote it
some time ago but I think that it should work for you.
It is able to use engine's or vdsm's certificates.

Thanks,
Piotr

[1] https://github.com/pkliczewski/vdsm-smoke

On Thu, Sep 7, 2017 at 8:54 AM, pengyixiang  wrote:
> hello, everyone!
> I try to run JsonRpcClient to call "Host.getCapabilities" without a
> running ovirt engine but with a running vdsm, so I write a case to run this
> file:
> backend/manager/modules/vdsbroker/src/test/java/org/ovirt/engine/core/vdsbroker/jsonrpc/JsonRpcIntegrationTest.java
>
>  but it's seems failed, logs follows:
>
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Loaded file
> '/home/pencc/eclipse-workspace/engine_rpc_test/src/main/resources/engine.conf.defaults'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - The file
> '/etc/ovirt-engine/engine.conf' doesn't exist or isn't readable. Will return
> an empty set of properties.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - The file
> '/etc/ovirt-engine/engine.conf.d/10-setup-database.conf' doesn't exist or
> isn't readable. Will return an empty set of properties.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Loaded file
> '/etc/ovirt-engine/engine.conf.d/10-setup-java.conf'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Loaded file
> '/etc/ovirt-engine/engine.conf.d/10-setup-jboss.conf'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - The file
> '/etc/ovirt-engine/engine.conf.d/10-setup-pki.conf' doesn't exist or isn't
> readable. Will return an empty set of properties.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Loaded file
> '/etc/ovirt-engine/engine.conf.d/10-setup-protocols.conf'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - The file
> '/etc/ovirt-engine/engine.conf.d/11-setup-sso.conf' doesn't exist or isn't
> readable. Will return an empty set of properties.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Loaded file
> '/etc/ovirt-engine/engine.conf.d/20-setup-jboss-overlay.conf'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_AJP_ENABLED' is 'false'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_AJP_PORT' is 'None'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_DB_CHECK_INTERVAL' is '0'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_DB_CONNECTION_TIMEOUT' is '0'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_DEBUG_ADDRESS' is '127.0.0.1:8787'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_DEPLOYMENT_SCANNER' is 'true'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_ETC' is './'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_FQDN' is 'ovirt.linx.com'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_HEAP_MAX' is '3979M'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_HEAP_MIN' is '3979M'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_HTTPS_ENABLED' is 'true'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_HTTPS_PORT' is '8443'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_HTTP_ENABLED' is 'true'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_HTTP_PORT' is '8080'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_JAVA_MODULEPATH' is
> '/usr/share/ovirt-engine-wildfly-overlay/modules:'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_LOG_TO_CONSOLE' is 'true'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_PKI_ENGINE_STORE' is 'src/main/resources/key.p12'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_PKI_ENGINE_STORE_ALIAS' is '1'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_PKI_ENGINE_STORE_PASSWORD' is 'NoSoup4U'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_PKI_ENGINE_STORE_TYPE' is 'PKCS12'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_PKI_TRUST_STORE' is 'src/main/resources/truststore'.
> [main] INFO org.ovirt.engine.core.uutils.config.ShellLikeConfd - Value of
> property 'ENGINE_PKI_TRUST_STORE_PASSWORD' is ''.
> [main] INFO 

Re: [ovirt-devel] how to print api method name and params in ovirt

[Piotr Kliczewski]

On Tue, Sep 5, 2017 at 7:39 AM, Roy Golan  wrote:
> This might help you Bug 1479301 - [RFE] Add elapsed times of operations to
> the engine.log
>
>
>
> On Tue, 5 Sep 2017 at 06:29 pengyixiang  wrote:
>>
>> hello, everyone!
>> We need to customed ovirt, and now I need to know which api been
>> called and transport's params after button been pushed in engine, I try to
>> add logs like this in vdsm:
>>
>>  455 @api.method
>>  456 def hotplugDisk(self, params):
>>  457 syslog.syslog("---in VM hotplugDisk")
>>  458 syslog.syslog("params:%s" % (params))
>>  459 try:
>>  460 utils.validateMinimalKeySet(params, ('vmId', 'drive'))
>>  461 except ValueError:
>>  462 self.log.error('Missing one of required parameters: vmId,
>> drive')
>>  463 return {'status': {'code':
>> errCode['MissParam']['status']['code'],
>>  464'message': 'Missing one of required '
>>  465   'parameters: vmId, drive'}}
>>  466 return self.vm.hotplugDisk(params)
>>
>> but the number of api method is too much,  where should I add is better to
>> print called api method name and params?
>>

I think you are looking for this [1] in vdsm or this [2] in the engine.
It is enough to increase log level on both sides.

[1] https://github.com/oVirt/vdsm/blob/master/lib/yajsonrpc/__init__.py#L646
[2] 
https://github.com/oVirt/vdsm-jsonrpc-java/blob/master/client/src/main/java/org/ovirt/vdsm/jsonrpc/client/reactors/stomp/StompCommonClient.java#L56

>>
>>
>>
>>
>> ___
>> 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] hosted engine job fails starting VM

[Piotr Kliczewski]

On Tue, Sep 5, 2017 at 9:04 AM, Sandro Bonazzola 
wrote:

> http://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-suite-master/20/artifact/exported-artifacts/test_logs/he-basic-suite-master/post-002_bootstrap.py/lago-he-basic-suite-master-host0/
>
> In hosted engine setup logs:
>
> 2017-09-04 23:06:33,705-0400 DEBUG otopi.plugins.gr_he_setup.vm.runvm 
> mixins._create_vm:283 {u'status': {'message': 'Done', 'code': 0}, 
> u'emulatedMachine': u'pc', u'vmId': u'cef091fe-ff3e-4a90-b2f1-674773eac4ce', 
> u'devices': [{u'device': u'scsi', u'model': u'virtio-scsi', u'type': 
> u'controller'}, {u'device': u'console', u'specParams': {u'enableSocket': 
> u'true'}, u'type': u'console', u'deviceId': 
> u'494ce6e1-b43d-4c57-acd7-7a6c4943cc5a', u'alias': u'console0'}, {u'index': 
> u'2', u'iface': u'ide', u'specParams': {}, u'readonly': u'true', u'deviceId': 
> u'cfa4e0a2-6261-4055-b815-91bff9b78ab6', u'address': {u'bus': u'1', 
> u'controller': u'0', u'type': u'drive', u'target': u'0', u'unit': u'0'}, 
> u'device': u'cdrom', u'shared': u'false', u'path': 
> u'/tmp/tmpnlD4s1/seed.iso', u'type': u'disk'}, {u'index': u'0', u'iface': 
> u'virtio', u'format': u'raw', u'bootOrder': u'1', u'poolID': 
> u'----', u'volumeID': 
> u'e2a2e6cb-6f0f-4824-b581-e949ce07f612', u'imageID': 
> u'93d9c21e-b029-45a2-997f-ba5e65fcc9a2', u'specParams': {}, u'readonly': 
> u'false', u'domainID': u'6ae9f9dd-930b-4894-92e0-c9e3bfc0d875', u'optional': 
> u'false', u'deviceId': u'93d9c21e-b029-45a2-997f-ba5e65fcc9a2', u'address': 
> {u'slot': u'0x06', u'bus': u'0x00', u'domain': u'0x', u'type': u'pci', 
> u'function': u'0x0'}, u'device': u'disk', u'shared': u'exclusive', 
> u'propagateErrors': u'off', u'type': u'disk'}, {u'nicModel': u'pv', 
> u'macAddr': u'54:52:c0:a8:c8:63', u'linkActive': u'true', u'network': 
> u'ovirtmgmt', u'specParams': {}, u'deviceId': 
> u'977a4b82-06bb-48ee-b71c-5c87b88488af', u'address': {u'slot': u'0x03', 
> u'bus': u'0x00', u'domain': u'0x', u'type': u'pci', u'function': u'0x0'}, 
> u'device': u'bridge', u'type': u'interface'}, {u'device': u'vga', u'alias': 
> u'video0', u'type': u'video'}, {u'device': u'vnc', u'type': u'graphics'}, 
> {u'device': u'virtio', u'specParams': {u'source': u'urandom'}, u'model': 
> u'virtio', u'type': u'rng'}], u'guestDiskMapping': {}, u'vmType': u'kvm', 
> u'smp': u'2', u'display': u'vnc', u'memSize': 3171, u'cpuType': 
> u'SandyBridge', u'clientIp': u'', u'statusTime': u'4295135080', u'vmName': 
> u'HostedEngine', u'spiceSecureChannels': 
> u'smain,sdisplay,sinputs,scursor,splayback,srecord,ssmartcard,susbredir', 
> u'maxVCpus': u'2'}
> 2017-09-04 23:06:33,722-0400 DEBUG otopi.plugins.gr_he_setup.vm.runvm 
> mixins._create_vm:300 {'status': {'message': 'Done', 'code': 0}, 'items': 
> [{u'username': u'Unknown', u'displayInfo': [], u'hash': 
> u'4313467795400122059', u'acpiEnable': u'true', u'guestFQDN': u'', 
> u'monitorResponse': u'0', u'vmId': u'cef091fe-ff3e-4a90-b2f1-674773eac4ce', 
> u'kvmEnable': u'true', u'elapsedTime': u'0', u'vmType': u'kvm', u'session': 
> u'Unknown', u'status': u'WaitForLaunch', u'guestCPUCount': -1, u'appsList': 
> [], u'timeOffset': u'0', u'memUsage': u'0', u'guestIPs': u'', u'statusTime': 
> u'4295135100', u'vmName': u'HostedEngine', u'clientIp': u''}]}
> 2017-09-04 23:06:36,734-0400 DEBUG otopi.plugins.gr_he_setup.vm.runvm 
> mixins._create_vm:300 {'status': {'message': 'Done', 'code': 0}, 'items': 
> [{u'status': u'Down', u'exitMessage': u'invalid argument: could not find 
> capabilities for arch=x86_64 domaintype=kvm ', u'vmId': 
> u'cef091fe-ff3e-4a90-b2f1-674773eac4ce', u'exitReason': 1, u'statusTime': 
> u'4295138120', u'exitCode': 1}]}
> 2017-09-04 23:06:36,735-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-hosted-engine-setup/scripts/../plugins/gr-he-setup/vm/runvm.py",
>  line 168, in _boot_from_hd
> self._create_vm()
>   File 
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_setup/mixins.py", line 
> 315, in _create_vm
> 'The VM is not powering up: please check VDSM logs'
> RuntimeError: The VM is not powering up: please check VDSM logs
>
>
> In VDSM logs I see:
>
> 2017-09-04 23:06:33,702-0400 INFO  (vm/cef091fe) [vdsm.api] START 
> prepareImage(sdUUID=u'6ae9f9dd-930b-4894-92e0-c9e3bfc0d875', 
> spUUID=u'----', 
> imgUUID=u'93d9c21e-b029-45a2-997f-ba5e65fcc9a2', 
> leafUUID=u'e2a2e6cb-6f0f-4824-b581-e949ce07f612', allowIllegal=False) 
> from=internal, task_id=127e77e0-29cd-47e2-870f-491fb34a001d (api:46)
> 2017-09-04 23:06:33,708-0400 ERROR (jsonrpc/6) [virt.vm] 
> (vmId='cef091fe-ff3e-4a90-b2f1-674773eac4ce') Error fetching vm stats 
> (vm:1676)
> Traceback (most recent call last):
>   File 

[ovirt-devel] vdsm failed to start

[Piotr Kliczewski]

All,

I pulled the latest master and updated my vdsm. It failed to start and
I found following failure.
It was introduced by [1].

Am I missing something in my env?

Thanks,
Piotr

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


Sep  4 10:53:46 f20 vdsmd_init_common.sh[8508]: Traceback (most recent
call last):
Sep  4 10:53:46 f20 vdsmd_init_common.sh[8508]:  File
"/usr/bin/vdsm-tool", line 219, in main
Sep  4 10:53:46 f20 vdsmd_init_common.sh[8508]:return
tool_command[cmd]["command"](*args)
Sep  4 10:53:46 f20 vdsmd_init_common.sh[8508]:  File
"/usr/lib/python2.7/site-packages/vdsm/tool/__init__.py", line 38, in
wrapper
Sep  4 10:53:46 f20 vdsmd_init_common.sh[8508]:func(*args, **kwargs)
Sep  4 10:53:46 f20 vdsmd_init_common.sh[8508]:  File
"/usr/lib/python2.7/site-packages/vdsm/tool/configurator.py", line
160, in isconfigured
Sep  4 10:53:46 f20 vdsmd_init_common.sh[8508]:m = [c.name for c
in pargs.modules if _isconfigured(c) == configurators.NO]
Sep  4 10:53:46 f20 vdsmd_init_common.sh[8508]:  File
"/usr/lib/python2.7/site-packages/vdsm/tool/configurator.py", line 98,
in _isconfigured
Sep  4 10:53:46 f20 vdsmd_init_common.sh[8508]:return
getattr(module, 'isconfigured', lambda: configurators.NO)()
Sep  4 10:53:46 f20 vdsmd_init_common.sh[8508]:  File
"/usr/lib/python2.7/site-packages/vdsm/tool/configurators/sebool.py",
line 74, in isconfigured
Sep  4 10:53:46 f20 vdsmd_init_common.sh[8508]:if not
all(sebool_status[sebool_variable]):
Sep  4 10:53:46 f20 vdsmd_init_common.sh[8508]: KeyError: 'virt_use_glusterd'
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Slack channel

[Piotr Kliczewski]

On Sun, Sep 3, 2017 at 4:19 PM, Roy Golan  wrote:

>
>
> On Sun, 3 Sep 2017 at 17:11 Dan Kenigsberg  wrote:
>
>> Last time I checked, slack was not ready for real use. It lost my
>> confidence when it decided to hide my two weeks old chat because my group
>> account used up all its free resources.
>> That's closed-source mentality at its worst.
>>
>>
> Slacks unpaid gives keeps the team's recent 10k messages, so I'm not sure
> what went wrong there.
>
> What's your opinion about other suggestions?
>
> On Sep 3, 2017 16:09, "Roy Golan"  wrote:
>>
>> I think SLA uses is mostly and it works well for them but there isn't
>> much presence of all other teams on slack.
>>
>> Opening the discussion here, I think we need to give our community a push
>> here, and modernize the communication our channel. Lets consider:
>> - slack
>> - gitter
>>
>>
It seems like reasonable option. I am using it to communicate with manageiq
team and it works OK.
I have to admit that I am not heavy user so I would not be able to have
similar issues as Dan had with slack.

I think it worth trying.


> - self hosted service
>>
>> Slack experience is good, but again, wasn't adopted much further by
>> ovirt. Some folks prefer other OS solution.
>>
>> I think gitter plays nice for communities and uses your github identity
>> so its open for everyone. Slack is bit different in the approach. But I
>> don't have experience with gitter at all so help out here people who do.
>>
>> Self hosted service, like RocketChat, means $$$ and time, and is less
>> visible on the internet but has other advantages of course.
>>
>>
>> Sandro, Eyal maybe you already have something up your sleeve?
>>
>>
>> On Thu, 24 Aug 2017 at 16:00 Eyal Edri  wrote:
>>
>>> Marc,
>>> I just sent you an invitation, see if you can signup.
>>>
>>> On Thu, Aug 24, 2017 at 3:53 PM, Eyal Edri  wrote:
>>>
 I think Roy is mostly using it, so maybe he can update the settings.

 On Thu, Aug 24, 2017 at 3:48 PM, Marc Young <3vilpeng...@gmail.com>
 wrote:

> That slack team requires either an invite or an `@redhat.com` email
> to sign up
>
> On Wed, Aug 23, 2017 at 11:58 PM, Yaniv Kaul  wrote:
>
>>
>>
>> On Thu, Aug 24, 2017 at 6:03 AM, Greg Sheremeta 
>> wrote:
>>
>>> Some of the teams have dedicated slack channels. We don't have a
>>> global ovirt team one that I know of.
>>>
>>
>> There's https://ovirt.slack.com/ - but I'm not sure how used it is.
>> Y.
>>
>>
>>>
>>> You can disable connect / disconnect chatter with a setting in
>>> hexchat. And you can catch what you missed by using an irc proxy.
>>>
>>> Full disclosure : I love slack and would love to see us fully cut
>>> over.
>>>
>>> Greg Sheremeta, MBA
>>> Sr. Software Engineer
>>> Red Hat, Inc.
>>> gsher...@redhat.com
>>>
>>> On Aug 23, 2017 10:31 PM, "Marc Young" <3vilpeng...@gmail.com>
>>> wrote:
>>>
>>> Is there hope for slack over IRC?
>>>
>>> The problem with IRC is all the connect/disconnect chatter (and
>>> offline being a black hole)
>>>
>>> ___
>>> 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
>



 --

 Eyal edri


 ASSOCIATE MANAGER

 RHV DevOps

 EMEA VIRTUALIZATION R


 Red Hat EMEA 
  TRIED. TESTED. TRUSTED.
 
 phone: +972-9-7692018 <+972%209-769-2018>
 irc: eedri (on #tlv #rhev-dev #rhev-integ)

>>>
>>>
>>>
>>> --
>>>
>>> Eyal edri
>>>
>>>
>>> ASSOCIATE MANAGER
>>>
>>> RHV DevOps
>>>
>>> EMEA VIRTUALIZATION R
>>>
>>>
>>> Red Hat EMEA 
>>>  TRIED. TESTED. TRUSTED.
>>> 
>>> phone: +972-9-7692018 <+972%209-769-2018>
>>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>>
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
> ___
> 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] [devel] ovirt-engine NFE on master

[Piotr Kliczewski]

All,

I pulled the latest engine master [1] and I see following exception
below. Is it known issue?

Thanks,
Piotr

[1] Based on 34f4d69117d916e52a7b2d5032d64b8d1185448c

2017-09-01 13:35:38,829+02 ERROR
[org.ovirt.engine.core.bll.AddUnmanagedVmsCommand]
(DefaultQuartzScheduler10) [353095e7] Command
'org.ovirt.engine.core.bll.AddUnmanagedVmsCommand' failed: null
2017-09-01 13:35:38,829+02 ERROR
[org.ovirt.engine.core.bll.AddUnmanagedVmsCommand]
(DefaultQuartzScheduler10) [353095e7] Exception:
java.lang.NumberFormatException: null
at java.lang.Integer.parseInt(Integer.java:542) [rt.jar:1.8.0_141]
at java.lang.Integer.parseInt(Integer.java:615) [rt.jar:1.8.0_141]
at 
org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerObjectsBuilder.parseIntVdsProperty(VdsBrokerObjectsBuilder.java:775)
[vdsbroker.jar:]
at 
org.ovirt.engine.core.bll.AddUnmanagedVmsCommand.convertVm(AddUnmanagedVmsCommand.java:119)
[bll.jar:]
at 
org.ovirt.engine.core.bll.AddUnmanagedVmsCommand.executeCommand(AddUnmanagedVmsCommand.java:96)
[bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1202)
[bll.jar:]
at 
org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1342)
[bll.jar:]
at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1984)
[bll.jar:]
at 
org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164)
[utils.jar:]
at 
org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103)
[utils.jar:]
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ImageIO issues

[Piotr Kliczewski]

On Mon, Aug 28, 2017 at 1:03 PM, Yedidyah Bar David <d...@redhat.com> wrote:
> On Mon, Aug 28, 2017 at 1:42 PM, Piotr Kliczewski
> <piotr.kliczew...@gmail.com> wrote:
>> On Mon, Aug 28, 2017 at 12:29 PM, Yedidyah Bar David <d...@redhat.com> wrote:
>>> On Mon, Aug 28, 2017 at 1:18 PM, Piotr Kliczewski
>>> <piotr.kliczew...@gmail.com> wrote:
>>>> BTW, I see following log line every couple of seconds:
>>>>
>>>> 192.168.1.107 - - [28/Aug/2017 11:57:37] "OPTIONS
>>>> /images/db08fc46-76f3-448a-8899-acd14a7cda41 HTTP/1.1" 204 0
>>>> /usr/lib/python2.7/site-packages/urllib3/connection.py:344:
>>>> SubjectAltNameWarning: Certificate for 192.168.1.109 has no
>>>> `subjectAltName`, falling back to check for a `commonName` for now.
>>>> This feature is being removed by major browsers and deprecated by RFC
>>>> 2818. (See https://github.com/shazow/urllib3/issues/497 for details.)
>>>>   SubjectAltNameWarning
>>>
>>> Doesn't engine-setup say anything about this? See also:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1450293
>>>
>>
>> I am using firefox and for some time I see that the data is being sent
>> (later it crashes).
>> It seems to be a warning so it is not that important.
>
> I referred to the missing subjectAltName, not to the error below.
> When you run engine-setup, it should suggest renewing PKI. Does it?

I am using ovirt-engine-setup built on 24 of August and when I run it
I do not see this question.

>
>>
>>> No idea about the error below.
>>>
>>>>
>>>> As well as I see that errors are not in the logs but I need to check
>>>> journal to understand what are the failures.
>>>>
>>>> On Mon, Aug 28, 2017 at 12:13 PM, Piotr Kliczewski
>>>> <piotr.kliczew...@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> For some time I am attempting to upload 14GB image over my local
>>>>> network. I faced network service crash on my vdsm host (it runs
>>>>> imageio daemon). Now I got following issue:
>>>>> - daemon side:
>>>>>
>>>>> 2017-08-28 12:02:01,289 ERROR   (Thread-194) [web] 192.168.1.107 - PUT
>>>>> /db08fc46-76f3-448a-8899-acd14a7cda41 500 210 (263.16s)
>>>>> Traceback (most recent call last):
>>>>>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/web.py",
>>>>> line 48, in __call__
>>>>> resp = self.dispatch(request)
>>>>>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/web.py",
>>>>> line 73, in dispatch
>>>>> return method(*match.groups())
>>>>>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_daemon/server.py",
>>>>> line 162, in put
>>>>> op.run()
>>>>>   File 
>>>>> "/usr/lib/python2.7/site-packages/ovirt_imageio_common/directio.py",
>>>>> line 68, in run
>>>>> self._run()
>>>>>   File 
>>>>> "/usr/lib/python2.7/site-packages/ovirt_imageio_common/directio.py",
>>>>> line 156, in _run
>>>>> self._receive_chunk(dst, buf, count)
>>>>>   File 
>>>>> "/usr/lib/python2.7/site-packages/ovirt_imageio_common/directio.py",
>>>>> line 192, in _receive_chunk
>>>>> raise errors.PartialContent(self.size, self.done)
>>>>> PartialContent: Requested 8388608 bytes, available 6389760 bytes
>>>>>
>>>>> - proxy side:
>>>>>
>>>>> 192.168.1.107 - - [28/Aug/2017 12:01:56] "PUT
>>>>> /images/db08fc46-76f3-448a-8899-acd14a7cda41 HTTP/1.1" 500 59
>>>>> 
>>>>> Exception happened during processing of request from ('192.168.1.107', 
>>>>> 51716)
>>>>> Traceback (most recent call last):
>>>>>   File "/usr/lib64/python2.7/SocketServer.py", line 596, in
>>>>> process_request_thread
>>>>> self.finish_request(request, client_address)
>>>>>   File "/usr/lib64/python2.7/SocketServer.py", line 331, in finish_request
>>>>> self.RequestHandlerClass(request, client_address, self)
>>>>>   File "/usr/lib64/python2.7/SocketServer.py", line 654, in __init__
>>>>> self.finish()
>>>>>   File "/usr/lib64/python2.7/SocketServer.py", line 713, in finish
>>>>> self.wfile.close()
>>>>>   File "/usr/lib64/python2.7/socket.py", line 283, in close
>>>>> self.flush()
>>>>>   File "/usr/lib64/python2.7/socket.py", line 307, in flush
>>>>> self._sock.sendall(view[write_offset:write_offset+buffer_size])
>>>>>   File "/usr/lib64/python2.7/ssl.py", line 753, in sendall
>>>>> v = self.send(data[count:])
>>>>>   File "/usr/lib64/python2.7/ssl.py", line 719, in send
>>>>> v = self._sslobj.write(data)
>>>>> error: [Errno 32] Broken pipe
>>>>> 
>>>>>
>>>>> I am using sources from couple of days ago and running both services
>>>>> on fedora 25. Is it known issue or should I open BZ for it?
>>>>>
>>>>> Thanks,
>>>>> Piotr
>>>> ___
>>>> Devel mailing list
>>>> Devel@ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>>
>>> --
>>> Didi
>
>
>
> --
> Didi
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] ImageIO issues

[Piotr Kliczewski]

On Mon, Aug 28, 2017 at 12:29 PM, Yedidyah Bar David <d...@redhat.com> wrote:
> On Mon, Aug 28, 2017 at 1:18 PM, Piotr Kliczewski
> <piotr.kliczew...@gmail.com> wrote:
>> BTW, I see following log line every couple of seconds:
>>
>> 192.168.1.107 - - [28/Aug/2017 11:57:37] "OPTIONS
>> /images/db08fc46-76f3-448a-8899-acd14a7cda41 HTTP/1.1" 204 0
>> /usr/lib/python2.7/site-packages/urllib3/connection.py:344:
>> SubjectAltNameWarning: Certificate for 192.168.1.109 has no
>> `subjectAltName`, falling back to check for a `commonName` for now.
>> This feature is being removed by major browsers and deprecated by RFC
>> 2818. (See https://github.com/shazow/urllib3/issues/497 for details.)
>>   SubjectAltNameWarning
>
> Doesn't engine-setup say anything about this? See also:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1450293
>

I am using firefox and for some time I see that the data is being sent
(later it crashes).
It seems to be a warning so it is not that important.

> No idea about the error below.
>
>>
>> As well as I see that errors are not in the logs but I need to check
>> journal to understand what are the failures.
>>
>> On Mon, Aug 28, 2017 at 12:13 PM, Piotr Kliczewski
>> <piotr.kliczew...@gmail.com> wrote:
>>> Hi,
>>>
>>> For some time I am attempting to upload 14GB image over my local
>>> network. I faced network service crash on my vdsm host (it runs
>>> imageio daemon). Now I got following issue:
>>> - daemon side:
>>>
>>> 2017-08-28 12:02:01,289 ERROR   (Thread-194) [web] 192.168.1.107 - PUT
>>> /db08fc46-76f3-448a-8899-acd14a7cda41 500 210 (263.16s)
>>> Traceback (most recent call last):
>>>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/web.py",
>>> line 48, in __call__
>>> resp = self.dispatch(request)
>>>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/web.py",
>>> line 73, in dispatch
>>> return method(*match.groups())
>>>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_daemon/server.py",
>>> line 162, in put
>>> op.run()
>>>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/directio.py",
>>> line 68, in run
>>> self._run()
>>>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/directio.py",
>>> line 156, in _run
>>> self._receive_chunk(dst, buf, count)
>>>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/directio.py",
>>> line 192, in _receive_chunk
>>> raise errors.PartialContent(self.size, self.done)
>>> PartialContent: Requested 8388608 bytes, available 6389760 bytes
>>>
>>> - proxy side:
>>>
>>> 192.168.1.107 - - [28/Aug/2017 12:01:56] "PUT
>>> /images/db08fc46-76f3-448a-8899-acd14a7cda41 HTTP/1.1" 500 59
>>> 
>>> Exception happened during processing of request from ('192.168.1.107', 
>>> 51716)
>>> Traceback (most recent call last):
>>>   File "/usr/lib64/python2.7/SocketServer.py", line 596, in
>>> process_request_thread
>>> self.finish_request(request, client_address)
>>>   File "/usr/lib64/python2.7/SocketServer.py", line 331, in finish_request
>>> self.RequestHandlerClass(request, client_address, self)
>>>   File "/usr/lib64/python2.7/SocketServer.py", line 654, in __init__
>>> self.finish()
>>>   File "/usr/lib64/python2.7/SocketServer.py", line 713, in finish
>>> self.wfile.close()
>>>   File "/usr/lib64/python2.7/socket.py", line 283, in close
>>> self.flush()
>>>   File "/usr/lib64/python2.7/socket.py", line 307, in flush
>>> self._sock.sendall(view[write_offset:write_offset+buffer_size])
>>>   File "/usr/lib64/python2.7/ssl.py", line 753, in sendall
>>> v = self.send(data[count:])
>>>   File "/usr/lib64/python2.7/ssl.py", line 719, in send
>>> v = self._sslobj.write(data)
>>> error: [Errno 32] Broken pipe
>>> 
>>>
>>> I am using sources from couple of days ago and running both services
>>> on fedora 25. Is it known issue or should I open BZ for it?
>>>
>>> Thanks,
>>> Piotr
>> ___
>> 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] ImageIO issues

[Piotr Kliczewski]

BTW, I see following log line every couple of seconds:

192.168.1.107 - - [28/Aug/2017 11:57:37] "OPTIONS
/images/db08fc46-76f3-448a-8899-acd14a7cda41 HTTP/1.1" 204 0
/usr/lib/python2.7/site-packages/urllib3/connection.py:344:
SubjectAltNameWarning: Certificate for 192.168.1.109 has no
`subjectAltName`, falling back to check for a `commonName` for now.
This feature is being removed by major browsers and deprecated by RFC
2818. (See https://github.com/shazow/urllib3/issues/497 for details.)
  SubjectAltNameWarning

As well as I see that errors are not in the logs but I need to check
journal to understand what are the failures.

On Mon, Aug 28, 2017 at 12:13 PM, Piotr Kliczewski
<piotr.kliczew...@gmail.com> wrote:
> Hi,
>
> For some time I am attempting to upload 14GB image over my local
> network. I faced network service crash on my vdsm host (it runs
> imageio daemon). Now I got following issue:
> - daemon side:
>
> 2017-08-28 12:02:01,289 ERROR   (Thread-194) [web] 192.168.1.107 - PUT
> /db08fc46-76f3-448a-8899-acd14a7cda41 500 210 (263.16s)
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/web.py",
> line 48, in __call__
> resp = self.dispatch(request)
>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/web.py",
> line 73, in dispatch
> return method(*match.groups())
>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_daemon/server.py",
> line 162, in put
> op.run()
>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/directio.py",
> line 68, in run
> self._run()
>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/directio.py",
> line 156, in _run
> self._receive_chunk(dst, buf, count)
>   File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/directio.py",
> line 192, in _receive_chunk
> raise errors.PartialContent(self.size, self.done)
> PartialContent: Requested 8388608 bytes, available 6389760 bytes
>
> - proxy side:
>
> 192.168.1.107 - - [28/Aug/2017 12:01:56] "PUT
> /images/db08fc46-76f3-448a-8899-acd14a7cda41 HTTP/1.1" 500 59
> 
> Exception happened during processing of request from ('192.168.1.107', 51716)
> Traceback (most recent call last):
>   File "/usr/lib64/python2.7/SocketServer.py", line 596, in
> process_request_thread
> self.finish_request(request, client_address)
>   File "/usr/lib64/python2.7/SocketServer.py", line 331, in finish_request
> self.RequestHandlerClass(request, client_address, self)
>   File "/usr/lib64/python2.7/SocketServer.py", line 654, in __init__
> self.finish()
>   File "/usr/lib64/python2.7/SocketServer.py", line 713, in finish
> self.wfile.close()
>   File "/usr/lib64/python2.7/socket.py", line 283, in close
> self.flush()
>   File "/usr/lib64/python2.7/socket.py", line 307, in flush
> self._sock.sendall(view[write_offset:write_offset+buffer_size])
>   File "/usr/lib64/python2.7/ssl.py", line 753, in sendall
> v = self.send(data[count:])
>   File "/usr/lib64/python2.7/ssl.py", line 719, in send
> v = self._sslobj.write(data)
> error: [Errno 32] Broken pipe
> 
>
> I am using sources from couple of days ago and running both services
> on fedora 25. Is it known issue or should I open BZ for it?
>
> Thanks,
> Piotr
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] ImageIO issues

[Piotr Kliczewski]

Hi,

For some time I am attempting to upload 14GB image over my local
network. I faced network service crash on my vdsm host (it runs
imageio daemon). Now I got following issue:
- daemon side:

2017-08-28 12:02:01,289 ERROR   (Thread-194) [web] 192.168.1.107 - PUT
/db08fc46-76f3-448a-8899-acd14a7cda41 500 210 (263.16s)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/web.py",
line 48, in __call__
resp = self.dispatch(request)
  File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/web.py",
line 73, in dispatch
return method(*match.groups())
  File "/usr/lib/python2.7/site-packages/ovirt_imageio_daemon/server.py",
line 162, in put
op.run()
  File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/directio.py",
line 68, in run
self._run()
  File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/directio.py",
line 156, in _run
self._receive_chunk(dst, buf, count)
  File "/usr/lib/python2.7/site-packages/ovirt_imageio_common/directio.py",
line 192, in _receive_chunk
raise errors.PartialContent(self.size, self.done)
PartialContent: Requested 8388608 bytes, available 6389760 bytes

- proxy side:

192.168.1.107 - - [28/Aug/2017 12:01:56] "PUT
/images/db08fc46-76f3-448a-8899-acd14a7cda41 HTTP/1.1" 500 59

Exception happened during processing of request from ('192.168.1.107', 51716)
Traceback (most recent call last):
  File "/usr/lib64/python2.7/SocketServer.py", line 596, in
process_request_thread
self.finish_request(request, client_address)
  File "/usr/lib64/python2.7/SocketServer.py", line 331, in finish_request
self.RequestHandlerClass(request, client_address, self)
  File "/usr/lib64/python2.7/SocketServer.py", line 654, in __init__
self.finish()
  File "/usr/lib64/python2.7/SocketServer.py", line 713, in finish
self.wfile.close()
  File "/usr/lib64/python2.7/socket.py", line 283, in close
self.flush()
  File "/usr/lib64/python2.7/socket.py", line 307, in flush
self._sock.sendall(view[write_offset:write_offset+buffer_size])
  File "/usr/lib64/python2.7/ssl.py", line 753, in sendall
v = self.send(data[count:])
  File "/usr/lib64/python2.7/ssl.py", line 719, in send
v = self._sslobj.write(data)
error: [Errno 32] Broken pipe


I am using sources from couple of days ago and running both services
on fedora 25. Is it known issue or should I open BZ for it?

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

Re: [ovirt-devel] vdsm vds.dispatcher

[Piotr Kliczewski]

This change was backported to 4.1 and you can find it in 4.19.7+.

This log entry appears in the logs when a client disconnects. 3
seconds is much too often and the only client could do it is mom
(adding Martin to confirm).

On Mon, Aug 28, 2017 at 12:11 AM, Gary Pedretty <g...@ravnalaska.net> wrote:
> vdsm-4.18.21-1.el7.centos.x86_64
>
> the entries are about every 3 seconds on all hosts
>
>
> 
> Gary Pedrettyg...@ravnalaska.net
> Systems Manager  www.flyravn.com
> Ravn Alaska   /\907-450-7251
> 5245 Airport Industrial Road /  \/\ 907-450-7238 fax
> Fairbanks, Alaska  99709/\  /\ \ Second greatest commandment
> Serving All of Alaska  /  \/  /\  \ \/\   “Love your neighbor as
> Green, green as far as the eyes can see yourself” Matt 22:39
> ----
>
>
>
>
> On Aug 27, 2017, at 12:46 PM, Piotr Kliczewski <piotr.kliczew...@gmail.com>
> wrote:
>
> Hello,
>
> This is not an error and it was modified to reduce logging level.
> Which vdsm version are you using?
>
> Thanks,
> Piotr
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] vdsm vds.dispatcher

[Piotr Kliczewski]

Hello,

This is not an error and it was modified to reduce logging level.
Which vdsm version are you using?

Thanks,
Piotr

On Sun, Aug 27, 2017 at 7:27 PM, Gary Pedretty  wrote:
> Why on even a new clean install of a glusterized self-hosted engine setup do
> all the hosts fill the messages log with
>
> journal: vdsm vds.dispatcher ERROR SSL error during reading data: unexpected
> eof
> journal: vdsm vds.dispatcher ERROR SSL error during reading data: unexpected
> eof
> journal: vdsm vds.dispatcher ERROR SSL error during reading data: unexpected
> eof
> journal: vdsm vds.dispatcher ERROR SSL error during reading data: unexpected
> eof
> journal: vdsm vds.dispatcher ERROR SSL error during reading data: unexpected
> eof
>
>
> An entry every few seconds even with no VMs setup and just the hosted engine
> running.  I know it is listed as a bug on redhat bugzilla page, but is this
> going to be normal until version 4.2 comes out?
>
> Gary
>
> 
> Gary Pedrettyg...@ravnalaska.net
> Systems Manager  www.flyravn.com
> Ravn Alaska   /\907-450-7251
> 5245 Airport Industrial Road /  \/\ 907-450-7238 fax
> Fairbanks, Alaska  99709/\  /\ \ Second greatest commandment
> Serving All of Alaska  /  \/  /\  \ \/\   “Love your neighbor as
> Green, green as far as the eyes can see yourself” Matt 22:39
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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] Mocks for oVirt Python SDK code

[Piotr Kliczewski]

On Mon, Aug 14, 2017 at 1:39 PM, Barak Korren  wrote:
> On 14 August 2017 at 14:21, Yaniv Kaul  wrote:
>> I was wondering if there are any examples of mocks written for code written
>> on top of the oVirt Python SDK.
>> I would assume there will be a different a call mocking sdk.Connection()
>> that would return a mock'ed object and from there continue?
>>
>> Context: I'm looking into writing an oVirt driver for some project. They
>> (rightfully so) ask for unit tests, using mocks, fixtures, etc. I'm unsure
>> this is really going to be easy or meaningful, but I thought I'd look into
>> it...

We used [1] in ovirt provider to record http interactions and replay them during
specific unit tests. For python there is [2] and it could be used in the same
way. Sadly sdk uses native client so it is not that easy to record interactions.
As workaround we started to dump objects to yaml [3] during recording run
and later load them during the tests.

[1] https://rubygems.org/gems/vcr/versions/3.0.3
[2] https://github.com/kevin1024/vcrpy
[3] 
https://github.com/ManageIQ/manageiq-providers-ovirt/tree/master/spec/models/manageiq/providers/redhat/infra_manager/refresh/refresher/response_yamls

>
> A little aside, but I typically find that if you have to write any
> mocks of your own rather then using the python-mock package
> (unitest.mock in Python3), it means you're probably doing systems
> tests instead of unit tests, or your code design is not very testable.
>
> --
> 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] [proposal] deprecate VDSM ping in favor of ping2 and confirmConnectivity

[Piotr Kliczewski]

On Tue, Aug 8, 2017 at 2:50 PM, Roy Golan  wrote:
> This is for 4.1 https://gerrit.ovirt.org/#/c/78916/ , track that, it should
> be in.
>

Irit's work is about providing reconnect logic which was not
implemented till now.

I think that introducing ping2 won't solve the issue for all our
cases. As Martin
mentioned we already have HE and mom calling 'ping' (both local).

When introducing fix for this issue we need to consider backward compatibility
for setupNetworks, HE and mom.


> On Tue, 8 Aug 2017 at 15:10 Martin Sivak  wrote:
>>
>> What stomp heartbeat? There is no such thing in the Python json rpc
>> client.
>>
>> Martin
>>
>> On Tue, Aug 8, 2017 at 1:04 PM, Roy Golan  wrote:
>> > Why isn't the stomp heartbeat enough?
>> >
>> > On Tue, 8 Aug 2017 at 13:45 Martin Sivak  wrote:
>> >>
>> >> MOM and hosted engine use the ping verb to verify the connection is
>> >> still OK. The RPC client did not have any reconnect logic in the past
>> >> (and I think it still does not..).
>> >>
>> >> Martin
>> >>
>> >> On Tue, Aug 8, 2017 at 12:01 PM, Roy Golan  wrote:
>> >> > Petr, why do you need the ping verb? what are you after?
>> >> >
>> >> > On Tue, 8 Aug 2017 at 11:54 Martin Sivak  wrote:
>> >> >>
>> >> >> > The proposed solution is focused on making sure a command does one
>> >> >> > thing
>> >> >> > and
>> >> >> > not two:
>> >> >> > A ping that has no side effects and a "watchdog" mechanism to
>> >> >> > confirm
>> >> >> > connectivity.
>> >> >>
>> >> >> This sounds as exactly the right solution right now.
>> >> >>
>> >> >> >>> Still someone could call conirmConnectivity, no?
>> >> >>
>> >> >> We do not protect any other endpoints that can cause the host to go
>> >> >> wild (storage or even setupNetworks). I agree with Edward it is the
>> >> >> responsibility of the caller to do the right thing. You need to be
>> >> >> root or have the certificate to talk to VDSM anyway.
>> >> >>
>> >> >> Martin
>> >> >>
>> >> >> On Tue, Aug 8, 2017 at 8:24 AM, Edward Haas 
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> > On Mon, Aug 7, 2017 at 11:06 PM, Nir Soffer 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Mon, Aug 7, 2017 at 5:28 PM Roy Golan 
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> Still someone could call conirmConnectivity, no? so the state
>> >> >> >>> isn't
>> >> >> >>> guarded from localhost tinkering anyhow. If you really need a
>> >> >> >>> solution
>> >> >> >>> you
>> >> >> >>> can acuire a token for this operation by setupNetworks, and
>> >> >> >>> confirm
>> >> >> >>> connectivity with this token passed back.
>> >> >> >>>
>> >> >> >>> I'm not sure about the severity of the problem here, I'll let
>> >> >> >>> other
>> >> >> >>> reply, but I'm against this kind of solution.
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> On Mon, 7 Aug 2017 at 15:32 Petr Horacek 
>> >> >> >>> wrote:
>> >> >> 
>> >> >>  Hello,
>> >> >> 
>> >> >>  current VDSM ping verb has a problem - it confirms network
>> >> >>  connectivity as a side-effect. After Engine calls setupNetwork
>> >> >>  it
>> >> >>  pings VDSM host to confirm that external network connectivity
>> >> >>  is
>> >> >>  not
>> >> >>  broken. This prohibits other users to call ping from localhost
>> >> >>  since
>> >> >>  it would confirm connectivity even though networking could be
>> >> >>  broken.
>> >> >> >>
>> >> >> >>
>> >> >> >> Vdsm can save the client ip setting up the network. Getting a
>> >> >> >> ping
>> >> >> >> from
>> >> >> >> this
>> >> >> >> client can confirm that the connectivity was restored. pings from
>> >> >> >> other
>> >> >> >> hosts
>> >> >> >> can be ignored.
>> >> >> >>
>> >> >> >> The client address is available in a thread local variable
>> >> >> >> (context.client_host)
>> >> >> >> during all api calls. see vdsm.common.api.context_string() for
>> >> >> >> example
>> >> >> >> usage.
>> >> >> >>
>> >> >> >> This infrastructure is available in 4.1.
>> >> >> >
>> >> >> >
>> >> >> > The proposed solution is focused on making sure a command does one
>> >> >> > thing
>> >> >> > and
>> >> >> > not two:
>> >> >> > A ping that has no side effects and a "watchdog" mechanism to
>> >> >> > confirm
>> >> >> > connectivity.
>> >> >> >
>> >> >> > Does it make sense to confirm connectivity from localhost? In many
>> >> >> > cases
>> >> >> > it
>> >> >> > probably does not,
>> >> >> > but there may be cases where it does make sense... it is not the
>> >> >> > functionality to determine what
>> >> >> > makes sense or not, it is the usage of it who has the
>> >> >> > responsibility
>> >> >> > to
>> >> >> > use
>> >> >> > it correctly.
>> >> >> >
>> >> >> >>
>> >> >> >> Nir
>> >> >> >>
>> >> >> 
>> >> >> 
>> >> >>  In order to fix this problem ping should be split to ping2
>> >> >>  (which
>> >> 

Re: [ovirt-devel] jsonrpc go client

[Piotr Kliczewski]

On Sun, Jul 16, 2017 at 7:02 PM, Yaniv Bronheim <ybron...@redhat.com> wrote:
> It depends who will be the users of this client.. For now, this only
> experimental for your plays around kubernetes, not more than that..
>
> On Sun, Jul 16, 2017 at 6:10 PM Nir Soffer <nsof...@redhat.com> wrote:
>>
>> Cool!
>>
>> This needs integration tests with real vdsm, or at least a server using
>> vdsm
>> yajsonrpc code. I'm worried about incompatibilities between the go stomp
>> library and our own stomp implementation, not used by any other code.

I don't mind making it production ready. With current code I wanted to
enable Adam
and his storage changes.

Let's discuss the details offline.

>>
>> When it works, we can convert vdsm-client to go :-)
>>
>> On Sat, Jul 15, 2017 at 8:53 AM Yaniv Bronheim <ybron...@redhat.com>
>> wrote:
>>>
>>> Great! make it official under ovirt imo . This will be totally useful
>>> later on with openshift integration. Im almost convinced that once ovirt
>>> will run in parallel to openshift or as part of openshift, we'll need to
>>> call vdsm api commands via modules that with high chance will be written in
>>> go. Give specific example won't be meaningful much because we still
>>> designing all this vm+containers architecture and flows.
>>> Thanks
>>>
>>> On Fri, Jul 14, 2017 at 4:40 PM Adam Litke <ali...@redhat.com> wrote:
>>>>
>>>> On Fri, Jul 14, 2017 at 9:32 AM, Piotr Kliczewski
>>>> <piotr.kliczew...@gmail.com> wrote:
>>>>>
>>>>> On Fri, Jul 14, 2017 at 3:14 PM, Dan Kenigsberg <dan...@redhat.com>
>>>>> wrote:
>>>>> > On Fri, Jul 14, 2017 at 3:11 PM, Piotr Kliczewski
>>>>> > <piotr.kliczew...@gmail.com> wrote:
>>>>> >> All,
>>>>> >>
>>>>> >> I pushed very simple jsonrpc go client [1] which allows to talk to
>>>>> >> vdsm. I had a request to create it but if there are more people
>>>>> >> willing to use it I am happy to maintain it.
>>>>
>>>>
>>>> Awesome Piotr!  Thanks for the great work.
>>>>
>>>>>
>>>>> >>
>>>>> >> Please let me know if you find any issues with it or you have any
>>>>> >> feature requests.
>>>>> >
>>>>> > Interesting. Which use case do you see for this client?
>>>>> > Currently, Vdsm has very few clients: Engine, vdsm-client, mom and
>>>>> > hosted-engine. Too often we forget about the non-Engine ones and
>>>>> > break
>>>>> > them, so I'd be happy to learn more about a 5th.
>>>>>
>>>>> Adam asked for the client for his storage related changes. I am not
>>>>> sure about specific use case.
>>>>
>>>>
>>>> I am looking at implementing a vdsm flexvol driver for kubernetes.  This
>>>> would allow kubernetes pods to access vdsm volumes using the native PV and
>>>> PVC mechanisms.
>>>>
>>>>>
>>>>>
>>>>> >
>>>>> > Regarding
>>>>> > https://github.com/pkliczewski/vdsm-jsonrpc-go/blob/master/example/main.go
>>>>> > : programming without exceptions and try-except is a pain. don't you
>>>>> > need to check the retval of Subscribe and disconnect on failure?
>>>>>
>>>>> By no means example is not perfect and you are correct. I will fix.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Adam Litke
>>>> ___
>>>> 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
>
> --
> Yaniv Bronhaim.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] jsonrpc go client

[Piotr Kliczewski]

On Fri, Jul 14, 2017 at 3:14 PM, Dan Kenigsberg <dan...@redhat.com> wrote:
> On Fri, Jul 14, 2017 at 3:11 PM, Piotr Kliczewski
> <piotr.kliczew...@gmail.com> wrote:
>> All,
>>
>> I pushed very simple jsonrpc go client [1] which allows to talk to
>> vdsm. I had a request to create it but if there are more people
>> willing to use it I am happy to maintain it.
>>
>> Please let me know if you find any issues with it or you have any
>> feature requests.
>
> Interesting. Which use case do you see for this client?
> Currently, Vdsm has very few clients: Engine, vdsm-client, mom and
> hosted-engine. Too often we forget about the non-Engine ones and break
> them, so I'd be happy to learn more about a 5th.

Adam asked for the client for his storage related changes. I am not
sure about specific use case.

>
> Regarding 
> https://github.com/pkliczewski/vdsm-jsonrpc-go/blob/master/example/main.go
> : programming without exceptions and try-except is a pain. don't you
> need to check the retval of Subscribe and disconnect on failure?

By no means example is not perfect and you are correct. I will fix.
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] jsonrpc go client

[Piotr Kliczewski]

All,

I pushed very simple jsonrpc go client [1] which allows to talk to
vdsm. I had a request to create it but if there are more people
willing to use it I am happy to maintain it.

Please let me know if you find any issues with it or you have any
feature requests.

Thanks,
Piotr


[1] https://github.com/pkliczewski/vdsm-jsonrpc-go
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] Chaning the statistics monitoring interval to 30s

[Piotr Kliczewski]

On Sun, Jul 9, 2017 at 4:52 PM, Roy Golan  wrote:

>
>
> On Thu, Jul 6, 2017 at 8:10 PM Nir Soffer  wrote:
>
>> On Wed, Jul 5, 2017 at 5:57 PM Roy Golan  wrote:
>>
>>> Hi all,
>>>
>>> I would like to get feedback on $subject and see if I'm missing
>>> something. The impact of this is simply less resource consumption and by
>>> that we can support even greater number of hosts [1] and vms in the system.
>>>
>>> If you think more relaxed statistics collection will affect a core flow
>>> let me know - as far as I see I didn't spot anything critical.
>>>
>>> The overhead of a cycle per host something like that: 2 roundtrips per
>>> host in a cycle, (vm + host stats) and tons of memory allocation for char[]
>>> -> json-> maps of maps -> VM/Vds statistics -> Maps -> serialiazing to DB.
>>>
>>> To minimize the effect of this change we can leave a call to 'list' verb
>>> to at least detect vms existence in the same rate as today.
>>>
>>> Pros
>>> - Engine has rore resources to support more hosts/vms/other activities
>>> of the engine
>>> - Vdsm will have more resources as well (need to tweak vdsm to collect
>>> in the same
>>> frequency)
>>> - less DB writes and reads, approx half of what the system will do in
>>> the in its lifefpan (cause this is what is mainly does all the time)
>>>
>>> Cons
>>> - DWH/Dashboard will have less entries, I'm not sure what is graphical
>>> affect given our hourly resolution (cmiiw here)
>>>
>>
>> Why we have a monitoring interval at all? why not move the stats to
>> events?
>>
>>
> Events is not suited for everything and the current vdsm can only
> guarantee 'at most once' semantics. We can not rely on that and that is why
> we poll.
>

I agree with the guarantees we have but why they are not enough for stats.
Are the stats so critical?


>
> Vdsm should collect stats and send updates to engine, engine can do only
>> polling only if vdsm did not send any update in the last couple of
>> minutes or so.
>>
>> Again you'd have to work harder to guarantee it . One of my main
> motivations here is to put as little effort as we can to gain more
> resources.
>
>
>> Same for stats collected by collectd, we want to stream updates to engine
>> from
>> the host, no poll every host for the stats.
>>
>> Again, not always - consider this, for example if we want to support big
> setups,  in the end they are going to stream huge amount of information to
> the engine - we would have a problem handling this pressure. Poll will
> allow us to choose who to poll and when.  (backpressure if that helps)
>

You have describe the issue that we have with poll. In large envs we have
constant time between the polls and single cycle takes longer. Back
pressure was implemented only on the engine side and vdsm side is still
missing.


>
> Nir
>>
>>
>>>
>>>
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1430876
>>> ___
>>> 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] Chaning the statistics monitoring interval to 30s

[Piotr Kliczewski]

On Thu, Jul 6, 2017 at 7:10 PM, Nir Soffer  wrote:
> On Wed, Jul 5, 2017 at 5:57 PM Roy Golan  wrote:
>>
>> Hi all,
>>
>> I would like to get feedback on $subject and see if I'm missing something.
>> The impact of this is simply less resource consumption and by that we can
>> support even greater number of hosts [1] and vms in the system.
>>
>> If you think more relaxed statistics collection will affect a core flow
>> let me know - as far as I see I didn't spot anything critical.
>>
>> The overhead of a cycle per host something like that: 2 roundtrips per
>> host in a cycle, (vm + host stats) and tons of memory allocation for char[]
>> -> json-> maps of maps -> VM/Vds statistics -> Maps -> serialiazing to DB.
>>
>> To minimize the effect of this change we can leave a call to 'list' verb
>> to at least detect vms existence in the same rate as today.
>>
>> Pros
>> - Engine has rore resources to support more hosts/vms/other activities of
>> the engine
>> - Vdsm will have more resources as well (need to tweak vdsm to collect in
>> the same
>> frequency)
>> - less DB writes and reads, approx half of what the system will do in the
>> in its lifefpan (cause this is what is mainly does all the time)
>>
>> Cons
>> - DWH/Dashboard will have less entries, I'm not sure what is graphical
>> affect given our hourly resolution (cmiiw here)
>
>
> Why we have a monitoring interval at all? why not move the stats to events?

It was one of the main reason to build event infrastructure. I
advocated for this
many times but it seems that the priority to have it done is very low.

Less work is required to change the polling cycle than to trigger
events even for
the cost of metric resolution.

>
> Vdsm should collect stats and send updates to engine, engine can do only
> polling only if vdsm did not send any update in the last couple of minutes
> or so.
>
> Same for stats collected by collectd, we want to stream updates to engine
> from
> the host, no poll every host for the stats.
>
> Nir
>
>>
>>
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1430876
>> ___
>> 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] [ OST Failure Report ] [ oVirt master ] [ 03-07-2017 ] [ 006_migrations.migrate_vm ]

[Piotr Kliczewski]

Looking at the last experimental job the reason of the failure is:

2017-07-04 09:39:10,491-04 ERROR
[org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default
task-18) [] Operation Failed: [Cannot run VM. There is no host that
satisfies current scheduling constraints. See below for details:, The host
lago-basic-suite-master-host0 did not satisfy internal filter CPUOverloaded
because its CPU is too loaded.]

Do we think that vdsm increased its cpu consumption recently?

On Tue, Jul 4, 2017 at 3:54 PM, Irit Goihman  wrote:

> I've checked vdsm logs and couldn't find anything related to my change.
> I'll run OST without my changes and see if it runs successfully.
>
> On Tue, Jul 4, 2017 at 4:49 PM, Eyal Edri  wrote:
>
>>
>>
>> On Tue, Jul 4, 2017 at 4:29 PM, Dafna Ron  wrote:
>>
>>> This issue is reproduced locally as well.
>>>
>>> you can run the following to reproduce locally
>>>
>>> ./run_suite.sh -s http://jenkins.ovirt.org/job/v
>>> dsm_master_build-artifacts-el7-x86_64/2694/ basic-suite-master
>>>
>>> you will have the environment still running which would allow to view
>>> the live environment.
>>> if you have any issues please ping me and I will help any way I can.
>>>
>>> Thanks,
>>> Dafna
>>>
>>>
>>>
>> Here is the list of changes done from the vdsm that is verified ( in
>> tested now ) to HEAD:
>>
>> * 74b2276 - (HEAD -> master, origin/master, origin/HEAD) stomp: add
>> integration tests for client reconnect (6 hours ago) Irit Goihman <
>> igoih...@redhat.com>
>> * 2a2f6cd - stomp: set default heartbeat values and add grace period (6
>> hours ago) Irit Goihman 
>> * 56c306a - tests: Make random uuid test repeatable (17 hours ago) Nir
>> Soffer 
>> * 864d4e3 - python3: Fix UUID packing/unpacking on python 3 (17 hours
>> ago) Nir Soffer 
>> * 4ac4221 - python3: Improve uuid packing tests (17 hours ago) Nir Soffer
>> 
>> * d264c8d - python3: Run misc_test in python 3 (17 hours ago) Nir Soffer <
>> nsof...@redhat.com>
>> * f923b0b - storage: Added disk type change logging (18 hours ago) Denis
>> Chaplygin 
>> * f1d54a1 - net: Unneeded newline is added when updating only the mtu (25
>> hours ago) Edward Haas 
>> * 9056d61 - virt: metadata: remove dead code (26 hours ago) Francesco
>> Romani 
>> * 08982b4 - virt: network: use core.find_device_guest_address (31 hours
>> ago) Francesco Romani 
>> * 62e2bc5 - python3: Run qcow2_test on python 3 (2 days ago) Nir Soffer <
>> nsof...@redhat.com>
>> * 42f5efb - stomp: implement client reconnect (2 days ago) Irit Goihman <
>> igoih...@redhat.com>
>>
>>
>>>
>>>
>>>
>>> On 07/04/2017 01:35 PM, Barak Korren wrote:
>>>
>>>
>>>
>>> On 4 July 2017 at 14:32, Irit Goihman  wrote:
>>>
 https://gerrit.ovirt.org/#/c/78536 broke network functional tests but
 a fix was merged today: https://gerrit.ovirt.org/#/c/78925/

 I tried to run OST with my fix yesterday and still encountered the same
 failures.

>>>
>>> Here is a reproducer of the failure with the fix patch:
>>> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/1061/
>>>
>>> So that was not it probably...
>>>
>>>
>>> --
>>> Barak Korren
>>> RHV DevOps team , RHCE, RHCi
>>> Red Hat EMEA
>>> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>>>
>>>
>>> ___
>>> Devel mailing 
>>> listDevel@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>>
>>> ___
>>> Devel mailing list
>>> Devel@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>>
>> --
>>
>> Eyal edri
>>
>>
>> ASSOCIATE MANAGER
>>
>> RHV DevOps
>>
>> EMEA VIRTUALIZATION R
>>
>>
>> Red Hat EMEA 
>>  TRIED. TESTED. TRUSTED. 
>> phone: +972-9-7692018 <+972%209-769-2018>
>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>
>
>
>
> --
>
> IRIT GOIHMAN
>
> SOFTWARE ENGINEER
>
> EMEA VIRTUALIZATION R
>
> Red Hat EMEA 
>
> 
> TRIED. TESTED. TRUSTED. 
> @redhatnews    Red Hat
>    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

Re: [ovirt-devel] vdsm-client getHardwareInfo takes X4 than vdsClient getVdsHardwareInfo

[Piotr Kliczewski]

Thanks

29 cze 2017 19:24 "Avihai Efrat" <aef...@redhat.com> napisał(a):

> Sure , Opened bz 1466461 on this issue.
>
> Link:
> https://bugzilla.redhat.com/show_bug.cgi?id=1466461
>
> On Thu, Jun 29, 2017 at 7:46 PM, Nir Soffer <nsof...@redhat.com> wrote:
>
>> Avihai, can you file a bug for this, and link to
>> https://bugzilla.redhat.com/show_bug.cgi?id=1381899#c17 ?
>>
>> On Thu, Jun 29, 2017 at 5:36 PM Piotr Kliczewski <pklic...@redhat.com>
>> wrote:
>>
>>> We could optimize it for one time use. Is there a BZ to track it?
>>>
>>> 29 cze 2017 15:57 "Nir Soffer" <nsof...@redhat.com> napisał(a):
>>>
>>>> On Thu, Jun 29, 2017 at 3:54 PM Avihai Efrat <aef...@redhat.com> wrote:
>>>>
>>>>> Hi Guys ,
>>>>>>>
>>>>>>> In ovirt 4.2 vdsClient is deprecated so using vdsm-client in tests I
>>>>>>> get timeout failures.
>>>>>>>
>>>>>>
>>>>>>> When I tested both utilities on a 4.1 host I noticed vdsm-client
>>>>>>> takes X4 than vdsClient .
>>>>>>>
>>>>>>> Is this known ?
>>>>>>>
>>>>>>> can we make it faster ?
>>>>>>>
>>>>>>> *Taken from client CLI :*
>>>>>>> [root@storage-ge3-vdsm1 ~]# time vdsClient -s 0 getVdsHardwareInfo
>>>>>>> systemFamily = 'Red Hat Enterprise Linux'
>>>>>>> systemManufacturer = 'Red Hat'
>>>>>>> systemProductName = 'RHEV Hypervisor'
>>>>>>> systemSerialNumber = '4C4C4544-0053-5410-8047-B9C04F465931'
>>>>>>> systemUUID = '07FD09C7-8461-4981-B859-A40C548E10FF'
>>>>>>> systemVersion = '7.2-9.el7_2.1'
>>>>>>>
>>>>>>> *real 0m0.382s*
>>>>>>> user 0m0.272s
>>>>>>> sys 0m0.056s
>>>>>>>
>>>>>>> [root@storage-ge3-vdsm1 ~]# time vdsm-client Host getHardwareInfo
>>>>>>> {
>>>>>>> "systemProductName": "RHEV Hypervisor",
>>>>>>> "systemSerialNumber": "4C4C4544-0053-5410-8047-B9C04F465931",
>>>>>>> "systemFamily": "Red Hat Enterprise Linux",
>>>>>>> "systemVersion": "7.2-9.el7_2.1",
>>>>>>> "systemUUID": "07FD09C7-8461-4981-B859-A40C548E10FF",
>>>>>>> "systemManufacturer": "Red Hat"
>>>>>>> }
>>>>>>>
>>>>>>> *real 0m1.208s*
>>>>>>> user 0m0.966s
>>>>>>> sys 0m0.111s
>>>>>>>
>>>>>>>
>>>> The difference is about 0.7 seconds. This can be explained by the
>>>> time needed to load the yaml schema - we load it for every request,
>>>> for validating the the request and generating online help.
>>>>
>>>> It takes about 0.1 seconds on a i7-4770 CPU @ 3.40GHz, but maybe you are
>>>> testing on a much slower machine, or your machine is overloaded for some
>>>> other reason?
>>>>
>>>> This was discussed in
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1381899#c17
>>>>
>>>> We can make this 100 times faster by using pickle format instead of
>>>> parsing
>>>> yaml.
>>>>
>>>> We can also make it infinitely faster by loading the schema only when
>>>> generating online help. There is no real need to validate the request
>>>> on the client side when the server side is already doing this.
>>>>
>>>> Nir
>>>>
>>>>
>
>
> --
>
> Regards ,
>
>
> Avihai EFRAT
>
> SENIOR QUALITY ENGINEER
>
> Red Hat Israel Ltd. <https://www.redhat.com/>
>
> 34 Jerusalem Road, Building A, 1st floor
>
> Ra'anana, Israel 4350109
>
> aef...@redhat.comT: +972-9-7692170/8272170
>  <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] vdsm-client getHardwareInfo takes X4 than vdsClient getVdsHardwareInfo

[Piotr Kliczewski]

We could optimize it for one time use. Is there a BZ to track it?

29 cze 2017 15:57 "Nir Soffer"  napisał(a):

> On Thu, Jun 29, 2017 at 3:54 PM Avihai Efrat  wrote:
>
>> Hi Guys ,

 In ovirt 4.2 vdsClient is deprecated so using vdsm-client in tests I
 get timeout failures.

>>>
 When I tested both utilities on a 4.1 host I noticed vdsm-client takes
 X4 than vdsClient .

 Is this known ?

 can we make it faster ?

 *Taken from client CLI :*
 [root@storage-ge3-vdsm1 ~]# time vdsClient -s 0 getVdsHardwareInfo
 systemFamily = 'Red Hat Enterprise Linux'
 systemManufacturer = 'Red Hat'
 systemProductName = 'RHEV Hypervisor'
 systemSerialNumber = '4C4C4544-0053-5410-8047-B9C04F465931'
 systemUUID = '07FD09C7-8461-4981-B859-A40C548E10FF'
 systemVersion = '7.2-9.el7_2.1'

 *real 0m0.382s*
 user 0m0.272s
 sys 0m0.056s

 [root@storage-ge3-vdsm1 ~]# time vdsm-client Host getHardwareInfo
 {
 "systemProductName": "RHEV Hypervisor",
 "systemSerialNumber": "4C4C4544-0053-5410-8047-B9C04F465931",
 "systemFamily": "Red Hat Enterprise Linux",
 "systemVersion": "7.2-9.el7_2.1",
 "systemUUID": "07FD09C7-8461-4981-B859-A40C548E10FF",
 "systemManufacturer": "Red Hat"
 }

 *real 0m1.208s*
 user 0m0.966s
 sys 0m0.111s


> The difference is about 0.7 seconds. This can be explained by the
> time needed to load the yaml schema - we load it for every request,
> for validating the the request and generating online help.
>
> It takes about 0.1 seconds on a i7-4770 CPU @ 3.40GHz, but maybe you are
> testing on a much slower machine, or your machine is overloaded for some
> other reason?
>
> This was discussed in
> https://bugzilla.redhat.com/show_bug.cgi?id=1381899#c17
>
> We can make this 100 times faster by using pickle format instead of parsing
> yaml.
>
> We can also make it infinitely faster by loading the schema only when
> generating online help. There is no real need to validate the request
> on the client side when the server side is already doing this.
>
> Nir
>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [oVirt Jenkins] ovirt_4.1_hc-system-tests - Build # 76 - Failure!

[Piotr Kliczewski]

This is the issue I described in the other thread. Engine you are using do
not have a patch [1].

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

On Thu, May 25, 2017 at 10:26 AM, Eyal Edri  wrote:

> Adding devel and Piotr.
>
> On Thu, May 25, 2017 at 9:31 AM, Sahina Bose  wrote:
>
>> Connecting to lago-hc-basic-suite-4-1-host0.lago.local/192.168.200.2
>> 2017-05-24 23:31:00,492-04 ERROR 
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] 
>> (org.ovirt.thread.pool-7-thread-1) [712d05a6] Error: 
>> org.ovirt.engine.core.vdsbroker.TransportRunTimeException: Connection issues 
>> during send request
>> 2017-05-24 23:31:00,492-04 ERROR 
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] 
>> (org.ovirt.thread.pool-7-thread-1) [712d05a6] Exception: 
>> java.util.concurrent.ExecutionException: 
>> org.ovirt.engine.core.vdsbroker.TransportRunTimeException: Connection issues 
>> during send request
>> Caused by: java.lang.ClassNotFoundException: 
>> org.apache.commons.lang.StringUtils from [Module 
>> "org.ovirt.vdsm-jsonrpc-java:main" from local module loader @5e91993f 
>> (finder: local module finder @1c4af82c (roots: 
>> /usr/share/ovirt-engine-wildfly-overlay/modules,/usr/share/ovirt-engine/modules/common,/usr/share/ovirt-engine-extension-aaa-jdbc/modules,/usr/share/ovirt-engine-wildfly/modules,/usr/share/ovirt-engine-wildfly/modules/system/layers/base))]
>>
>>
>> Known issue?
>>
>>
>> On Thu, May 25, 2017 at 9:16 AM,  wrote:
>>
>>> Project: http://jenkins.ovirt.org/job/ovirt_4.1_hc-system-tests/
>>> Build: http://jenkins.ovirt.org/job/ovirt_4.1_hc-system-tests/76/
>>> Build Number: 76
>>> Build Status:  Failure
>>> Triggered By: Started by timer
>>>
>>> -
>>> Changes Since Last Success:
>>> -
>>> Changes for Build #76
>>> [Ondřej Svoboda] Use SDKv4 code in add_labeled_network.
>>>
>>> [Barak Korren] Refactor: Use macros in defaults file
>>>
>>> [Barak Korren] Default values for 'arch' and 'distro' in STD-CI
>>>
>>>
>>>
>>>
>>> -
>>> Failed Tests:
>>> -
>>> 1 tests failed.
>>> FAILED:  002_bootstrap.add_hosts
>>>
>>> Error Message:
>>>
>>> status: 409
>>> reason: Conflict
>>> detail: Cannot add Host. There is no available server in the cluster to
>>> probe the new server.
>>>  >> begin captured logging << 
>>> lago.utils: ERROR: Error while running thread
>>> Traceback (most recent call last):
>>>   File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in
>>> _ret_via_queue
>>> queue.put({'return': func()})
>>>   File "/home/jenkins/workspace/ovirt_4.1_hc-system-tests/ovirt-sys
>>> tem-tests/hc-basic-suite-4.1/test-scenarios/002_bootstrap.py", line
>>> 141, in _add_host
>>> return api.hosts.add(p)
>>>   File 
>>> "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py",
>>> line 18306, in add
>>> headers={"Correlation-Id":correlation_id, "Expect":expect}
>>>   File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py",
>>> line 79, in add
>>> return self.request('POST', url, body, headers, cls=cls)
>>>   File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py",
>>> line 122, in request
>>> persistent_auth=self.__persistent_auth
>>>   File 
>>> "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py",
>>> line 79, in do_request
>>> persistent_auth)
>>>   File 
>>> "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py",
>>> line 162, in __do_request
>>> raise errors.RequestError(response_code, response_reason,
>>> response_body)
>>> RequestError:
>>> status: 409
>>> reason: Conflict
>>> detail: Cannot add Host. There is no available server in the cluster to
>>> probe the new server.
>>> lago.utils: ERROR: Error while running thread
>>> Traceback (most recent call last):
>>>   File "/usr/lib/python2.7/site-packages/lago/utils.py", line 58, in
>>> _ret_via_queue
>>> queue.put({'return': func()})
>>>   File "/home/jenkins/workspace/ovirt_4.1_hc-system-tests/ovirt-sys
>>> tem-tests/hc-basic-suite-4.1/test-scenarios/002_bootstrap.py", line
>>> 141, in _add_host
>>> return api.hosts.add(p)
>>>   File 
>>> "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py",
>>> line 18306, in add
>>> headers={"Correlation-Id":correlation_id, "Expect":expect}
>>>   File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py",
>>> line 79, in add
>>> return self.request('POST', url, body, headers, cls=cls)
>>>   File "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py",
>>> line 122, in request
>>> persistent_auth=self.__persistent_auth
>>>   File 
>>> "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/connectionspool.py",
>>> line 79, in do_request
>>> persistent_auth)
>>>   File 
>>> 

Re: [ovirt-devel] test-repo_ovirt_experimental_4.1 failing

[Piotr Kliczewski]

On Wed, May 24, 2017 at 3:17 PM, Eyal Edri <ee...@redhat.com> wrote:

>
>
> On Wed, May 24, 2017 at 4:10 PM, Piotr Kliczewski <
> piotr.kliczew...@gmail.com> wrote:
>
>> On Wed, May 24, 2017 at 2:39 PM, Dusan Fodor <dfo...@redhat.com> wrote:
>> > Hello all,
>> > experimental 4.1 is failing. Could anyone assist?
>> > [first failed job]
>> > So far i see 3 issues there:
>> >
>> > PollVDSCommand error, which has been discussed previously in thread
>> > [ovirt-devel] [OST Failure Report][oVirt master][2017-04-11]
>> > [log link]
>>
>> There is too new jsonrpc. In 4.1 this issue was fixed by [1]
>>
>
> What do mean by too new jsonrpc? you mean we have master version on 4.1
> repo?
>
>

No, I mean that I backported correlation_id support and 1,3,12 jsonrpc was
used where
the engine required 1.3.11.

We do not check it. Now the engine side patch was merged and it should be
fine now.


>
>> [1] https://gerrit.ovirt.org/#/c/77203/
>>
>> > wrong gdeploy package
>> > 2017-05-23 15:08:42,709::ERROR::root::Wrong distribution for package:
>> > gdeploy-2.0.2
>> > [log link]
>> > MOM couldn't connect to VDSM
>> > [log link]
>> >
>> >
>> > ___
>> > Devel mailing list
>> > Devel@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>
>
> --
>
> Eyal edri
>
>
> ASSOCIATE MANAGER
>
> RHV DevOps
>
> EMEA VIRTUALIZATION R
>
>
> Red Hat EMEA <https://www.redhat.com/>
> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
> phone: +972-9-7692018 <+972%209-769-2018>
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 14/05/2017 ] [ test-repo_ovirt_experimental_master ]

[Piotr Kliczewski]

Yevgeny,

There is message id which matches request and response but in this
case I made an assumption about setupNetworks being exclusive
operation.
The following setupNetwoks was the last one which was last executed.

Thanks,
Piotr

On Thu, May 18, 2017 at 1:28 PM, Yevgeny Zaspitsky <yzasp...@redhat.com> wrote:
> Piotr,
>
> How do you identify the connection between the 2 message, why do you think
> that the timeout is related to the first message you've mentioned?
>
> Regards,
> Yevgeny
>
> On Mon, May 15, 2017 at 12:40 PM, Piotr Kliczewski
> <piotr.kliczew...@gmail.com> wrote:
>>
>> I agree with Nir that the above issue is not related to the job failure.
>>
>> I see that there is a timeout for:
>>
>> 2017-05-14 04:10:04,215-04 DEBUG
>> [org.ovirt.vdsm.jsonrpc.client.reactors.stomp.StompCommonClient]
>> (org.ovirt.thread.pool-7-thread-12) [] Message sent: SEND
>> destination:jms.topic.vdsm_requests
>> content-length:377
>> reply-to:jms.topic.vdsm_responses
>>
>> > Host.setupNetworks, params: {networks={Migration_Net={vlan=200,
>> ipv6autoconf=false, nic=eth0, bridged=false, dhcpv6=false, mtu=1500,
>> ipv6addr=2001:0db8:85a3:::574c:14ea:0a02/64, switch=legacy}},
>> bondings={}, options={connectivityTimeout=120,
>> connectivityCheck=true}}>
>>
>>
>> and the timeout occurred at:
>>
>> 2017-05-14 04:10:07,535-04 DEBUG
>> [org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker]
>> (ResponseWorker) [] Message received:
>>
>> {"jsonrpc":"2.0","error":{"code":"lago-basic-suite-master-host1:286640862","message":"Vds
>> timeout occured"},"id":null}
>>
>> I see in supervdsm log:
>>
>> MainProcess|jsonrpc/1::INFO::2017-05-14
>> 04:10:05,566::netconfpersistence::52::root::(setNetwork) Adding
>> network Migration_Net({u'ipv6autoconf': False, 'nameservers': [],
>> u'nic': u'eth0', u'vlan': 200, u'mtu': 1500, u'switch': u'legacy',
>> u'dhcpv6': False, u'bridged': False, u'ipv6addr':
>> u'2001:0db8:85a3:::574c:14ea:0a02/64', 'defaultRoute': False,
>> 'bootproto': 'none'})
>> ...
>> MainProcess|jsonrpc/1::WARNING::2017-05-14
>> 04:10:05,580::ifcfg::247::root::(_addSourceRoute) Invalid input for
>> source routing: name=eth0.200, addr=None, netmask=None, gateway=None
>> netlink/events::DEBUG::2017-05-14
>> 04:10:05,581::concurrent::184::root::(run) START thread
>> <Thread(netlink/events, started daemon 139829765465856)> (func=> method Monitor._scan of > at 0x7f2c8c01ebd0>>, args=(), kwargs={})
>> MainProcess|jsonrpc/1::WARNING::2017-05-14
>> 04:10:05,581::ifcfg::894::root::(_ignore_missing_device) eth0.200
>> didn't exist (yet) and so IPv6 wasn't enabled.
>>
>> My question is why only 3 seconds to timeout setupNetworks.
>>
>>
>>
>> I found one more exception not related to the above issue which we should
>> fix:
>>
>> 2017-05-14 04:08:08,924-04 DEBUG
>> [org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl]
>> (DefaultQuartzScheduler10) [58fd90c1] Exception:
>> java.lang.reflect.InvocationTargetException
>> at sun.reflect.GeneratedMethodAccessor178.invoke(Unknown Source)
>> [:1.8.0_131]
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> [rt.jar:1.8.0_131]
>> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_131]
>> at
>> org.ovirt.engine.core.utils.timer.JobWrapper.invokeMethod(JobWrapper.java:83)
>> [scheduler.jar:]
>> at
>> org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:55)
>> [scheduler.jar:]
>> at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:]
>> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> [rt.jar:1.8.0_131]
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>> [rt.jar:1.8.0_131]
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> [rt.jar:1.8.0_131]
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> [rt.jar:1.8.0_131]
>> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
>> Caused by: java.lang.NullPointerException
>> at
>> org.ovirt.engine.core.vdsbroker.monitoring.VmStatsRefresher.lambda$processDevices$0(VmStatsRefresher.java:44)
>> [vdsbroker.jar:]
>> at
>> java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
>> [rt.jar:1.8.0_131]
>> at
>>

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 14/05/2017 ] [ test-repo_ovirt_experimental_master ]

[Piotr Kliczewski]

I agree with Nir that the above issue is not related to the job failure.

I see that there is a timeout for:

2017-05-14 04:10:04,215-04 DEBUG
[org.ovirt.vdsm.jsonrpc.client.reactors.stomp.StompCommonClient]
(org.ovirt.thread.pool-7-thread-12) [] Message sent: SEND
destination:jms.topic.vdsm_requests
content-length:377
reply-to:jms.topic.vdsm_responses




and the timeout occurred at:

2017-05-14 04:10:07,535-04 DEBUG
[org.ovirt.vdsm.jsonrpc.client.internal.ResponseWorker]
(ResponseWorker) [] Message received:
{"jsonrpc":"2.0","error":{"code":"lago-basic-suite-master-host1:286640862","message":"Vds
timeout occured"},"id":null}

I see in supervdsm log:

MainProcess|jsonrpc/1::INFO::2017-05-14
04:10:05,566::netconfpersistence::52::root::(setNetwork) Adding
network Migration_Net({u'ipv6autoconf': False, 'nameservers': [],
u'nic': u'eth0', u'vlan': 200, u'mtu': 1500, u'switch': u'legacy',
u'dhcpv6': False, u'bridged': False, u'ipv6addr':
u'2001:0db8:85a3:::574c:14ea:0a02/64', 'defaultRoute': False,
'bootproto': 'none'})
...
MainProcess|jsonrpc/1::WARNING::2017-05-14
04:10:05,580::ifcfg::247::root::(_addSourceRoute) Invalid input for
source routing: name=eth0.200, addr=None, netmask=None, gateway=None
netlink/events::DEBUG::2017-05-14
04:10:05,581::concurrent::184::root::(run) START thread
 (func=>, args=(), kwargs={})
MainProcess|jsonrpc/1::WARNING::2017-05-14
04:10:05,581::ifcfg::894::root::(_ignore_missing_device) eth0.200
didn't exist (yet) and so IPv6 wasn't enabled.

My question is why only 3 seconds to timeout setupNetworks.



I found one more exception not related to the above issue which we should fix:

2017-05-14 04:08:08,924-04 DEBUG
[org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl]
(DefaultQuartzScheduler10) [58fd90c1] Exception:
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor178.invoke(Unknown Source) [:1.8.0_131]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.8.0_131]
at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_131]
at org.ovirt.engine.core.utils.timer.JobWrapper.invokeMethod(JobWrapper.java:83)
[scheduler.jar:]
at org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:55)
[scheduler.jar:]
at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[rt.jar:1.8.0_131]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_131]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[rt.jar:1.8.0_131]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[rt.jar:1.8.0_131]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
Caused by: java.lang.NullPointerException
at 
org.ovirt.engine.core.vdsbroker.monitoring.VmStatsRefresher.lambda$processDevices$0(VmStatsRefresher.java:44)
[vdsbroker.jar:]
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
[rt.jar:1.8.0_131]
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
[rt.jar:1.8.0_131]
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
[rt.jar:1.8.0_131]
at 
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
[rt.jar:1.8.0_131]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
[rt.jar:1.8.0_131]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
[rt.jar:1.8.0_131]
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
[rt.jar:1.8.0_131]
at 
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
[rt.jar:1.8.0_131]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
[rt.jar:1.8.0_131]
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
[rt.jar:1.8.0_131]
at 
org.ovirt.engine.core.vdsbroker.monitoring.VmStatsRefresher.processDevices(VmStatsRefresher.java:46)
[vdsbroker.jar:]
at 
org.ovirt.engine.core.vdsbroker.monitoring.PollVmStatsRefresher.poll(PollVmStatsRefresher.java:44)
[vdsbroker.jar:]
... 11 more

Thanks,
Piotr


On Sun, May 14, 2017 at 6:12 PM, Nir Soffer  wrote:
> On Sun, May 14, 2017 at 5:14 PM Shlomo Ben David 
> wrote:
>>
>> Link to suspected patches: N/A
>> Link to Job:
>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6665/
>> Link to all logs:
>> http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/6665/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-006_migrations.py/
>>
>> Error snippet from the log:
>
>
>> Traceback (most recent call last):
>>
>>   File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 878,
>> in _run
>> return fn(*args, **kargs)
>>   File 

Re: [ovirt-devel] Vdsm merge rights

[Piotr Kliczewski]

+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-
> becbf722723417c336de6c1646749678acae8b89
> 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 ]

[Piotr Kliczewski]

It seems to be broken by this patch [1]


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

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

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 27-04-2017 ] [add_hosts]

[Piotr Kliczewski]

It is green now.

Thanks,
Piotr

On Sun, Apr 30, 2017 at 11:30 PM, Piotr Kliczewski <pklic...@redhat.com>
wrote:

> Thank you!
>
> 30 kwi 2017 23:14 "Nadav Goldin" <ngol...@redhat.com> napisał(a):
>
>> OK - that is easier as it involves only the master suite. Should be
>> fixed in [1], in [2] is the test run.
>>
>>
>> [1] https://gerrit.ovirt.org/#/c/76251/
>> [2] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/342/console
>>
>>
>> On Sun, Apr 30, 2017 at 10:39 PM, Piotr Kliczewski <pklic...@redhat.com>
>> wrote:
>> > I think it depends on which name we use when we add a host to the
>> engine.
>> > We need to be consistent and use the same host name when adding a host
>> and a
>> > fqdn for the host ip.
>> >
>> > On Sun, Apr 30, 2017 at 9:34 PM, Piotr Kliczewski
>> > <piotr.kliczew...@gmail.com> wrote:
>> >>
>> >> Nadav,
>> >>
>> >> Thank you for working on this but we have one more issue with name
>> >> resolution.
>> >>
>> >> I checked the last job you triggered and I noticed that vm migration
>> >> failed due to similar issue between the hosts.
>> >> Here is a piece of custom logs that you added:
>> >>
>> >> 2017-04-30 14:23:35,675-0400 INFO  (Reactor thread)
>> >> [ProtocolDetector.SSLHandshakeDispatcher] subject:
>> >> ((('organizationName', u'Test'),), (('commonName',
>> >> u'lago-basic-suite-master-host0'),)), key: organizationName, value:
>> >> Test (sslutils:241)
>> >> 2017-04-30 14:23:35,675-0400 INFO  (Reactor thread)
>> >> [ProtocolDetector.SSLHandshakeDispatcher] subject:
>> >> ((('organizationName', u'Test'),), (('commonName',
>> >> u'lago-basic-suite-master-host0'),)), key: commonName, value:
>> >> lago-basic-suite-master-host0 (sslutils:241)
>> >> 2017-04-30 14:23:35,676-0400 INFO  (Reactor thread)
>> >> [ProtocolDetector.SSLHandshakeDispatcher] src_addr:
>> >> :::192.168.201.2, cn_addr: lago-basic-suite-master-host0
>> >> (sslutils:262)
>> >> 2017-04-30 14:23:35,676-0400 INFO  (Reactor thread)
>> >> [ProtocolDetector.SSLHandshakeDispatcher] src_addr_extracted:
>> >> 192.168.201.2, cn_addr_extracted: lago-basic-suite-master-host0
>> >> (sslutils:266)
>> >> 2017-04-30 14:23:35,677-0400 INFO  (Reactor thread)
>> >> [ProtocolDetector.SSLHandshakeDispatcher]
>> >> socket.gethostbyadd(src_addr)[0]:
>> >> lago-basic-suite-master-host0.lago.local (sslutils:268)
>> >> 2017-04-30 14:23:35,678-0400 INFO  (Reactor thread)
>> >> [ProtocolDetector.SSLHandshakeDispatcher] compare
>> >> :::192.168.201.2, lago-basic-suite-master-host0, res: False
>> >> (sslutils:244)
>> >> 2017-04-30 14:23:35,678-0400 ERROR (Reactor thread)
>> >> [ProtocolDetector.SSLHandshakeDispatcher] peer certificate does not
>> >> match host name (sslutils:226)
>> >>
>> >> It looks like the engine issued certificate for
>> >> 'lago-basic-suite-master-host0' but we resolve 192.168.201.2 to
>> >> 'lago-basic-suite-master-host0.lago.local'.
>> >> Can we fix it as well?
>> >>
>> >> Thanks,
>> >> Piotr
>> >>
>> >> On Sun, Apr 30, 2017 at 7:42 PM, Piotr Kliczewski <pklic...@redhat.com
>> >
>> >> wrote:
>> >> > Wow, great.
>> >> >
>> >> > Thank you!
>> >> >
>> >> > 30 kwi 2017 19:40 "Nadav Goldin" <ngol...@redhat.com> napisał(a):
>> >> >>
>> >> >> Ok, I think the issue was the unqualified domain name. The
>> certificate
>> >> >> was generated(as before for 'engine') without the domain name, i.e.
>> >> >> 'lago-basic-suite-master-engine', on VDSM side it resolved the IP
>> to
>> >> >> the address 'lago-basic-suite-master-engine.lago.local' and then
>> >> >> failed comparing it to the unqualified one. I assume this is the
>> >> >> expected behaviour, though not sure(as you can easily resolve
>> >> >> 'lago-basic-suite-master-engine' to
>> >> >> 'lago-basic-suite-master-engine.lago.local' on the hosts). It
>> should
>> >> >> be fixed in [1], just ran OST manual with the same debugging patch
>> >> >> applied on top of yours, and at least add_hosts passed.
>> >> >>
>> >> >>
>> >> >> [1] https://gerrit.ovirt.org/#/c/76225/10
>> >> >> [2] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/338/c
>> onsole
>> >> >>
>> >> >> On Sun, Apr 30, 2017 at 7:50 PM, Piotr Kliczewski <
>> pklic...@redhat.com>
>> >> >> wrote:
>> >> >> > Sure, will take look later today.
>> >> >> >
>> >> >> > 30 kwi 2017 18:47 "Nadav Goldin" <ngol...@redhat.com> napisał(a):
>> >> >> >>
>> >> >> >> Thanks for the explanation.
>> >> >> >>
>> >> >> >> I added some more debugging messages on top of your patch, could
>> you
>> >> >> >> please take a look at [1] and tell me what do you expect to
>> resolve
>> >> >> >> differently for this to work?
>> >> >> >>
>> >> >> >>
>> >> >> >> [1]
>> >> >> >>
>> >> >> >>
>> >> >> >> http://jenkins.ovirt.org/job/ovirt-system-tests_manual/337/a
>> rtifact/exported-artifacts/test_logs/basic-suite-master/post
>> -002_bootstrap.py/lago-basic-suite-master-host0/_var_log/vdsm/vdsm.log
>> >
>> >
>>
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 27-04-2017 ] [add_hosts]

[Piotr Kliczewski]

Thank you!

30 kwi 2017 23:14 "Nadav Goldin" <ngol...@redhat.com> napisał(a):

> OK - that is easier as it involves only the master suite. Should be
> fixed in [1], in [2] is the test run.
>
>
> [1] https://gerrit.ovirt.org/#/c/76251/
> [2] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/342/console
>
>
> On Sun, Apr 30, 2017 at 10:39 PM, Piotr Kliczewski <pklic...@redhat.com>
> wrote:
> > I think it depends on which name we use when we add a host to the engine.
> > We need to be consistent and use the same host name when adding a host
> and a
> > fqdn for the host ip.
> >
> > On Sun, Apr 30, 2017 at 9:34 PM, Piotr Kliczewski
> > <piotr.kliczew...@gmail.com> wrote:
> >>
> >> Nadav,
> >>
> >> Thank you for working on this but we have one more issue with name
> >> resolution.
> >>
> >> I checked the last job you triggered and I noticed that vm migration
> >> failed due to similar issue between the hosts.
> >> Here is a piece of custom logs that you added:
> >>
> >> 2017-04-30 14:23:35,675-0400 INFO  (Reactor thread)
> >> [ProtocolDetector.SSLHandshakeDispatcher] subject:
> >> ((('organizationName', u'Test'),), (('commonName',
> >> u'lago-basic-suite-master-host0'),)), key: organizationName, value:
> >> Test (sslutils:241)
> >> 2017-04-30 14:23:35,675-0400 INFO  (Reactor thread)
> >> [ProtocolDetector.SSLHandshakeDispatcher] subject:
> >> ((('organizationName', u'Test'),), (('commonName',
> >> u'lago-basic-suite-master-host0'),)), key: commonName, value:
> >> lago-basic-suite-master-host0 (sslutils:241)
> >> 2017-04-30 14:23:35,676-0400 INFO  (Reactor thread)
> >> [ProtocolDetector.SSLHandshakeDispatcher] src_addr:
> >> :::192.168.201.2, cn_addr: lago-basic-suite-master-host0
> >> (sslutils:262)
> >> 2017-04-30 14:23:35,676-0400 INFO  (Reactor thread)
> >> [ProtocolDetector.SSLHandshakeDispatcher] src_addr_extracted:
> >> 192.168.201.2, cn_addr_extracted: lago-basic-suite-master-host0
> >> (sslutils:266)
> >> 2017-04-30 14:23:35,677-0400 INFO  (Reactor thread)
> >> [ProtocolDetector.SSLHandshakeDispatcher]
> >> socket.gethostbyadd(src_addr)[0]:
> >> lago-basic-suite-master-host0.lago.local (sslutils:268)
> >> 2017-04-30 14:23:35,678-0400 INFO  (Reactor thread)
> >> [ProtocolDetector.SSLHandshakeDispatcher] compare
> >> :::192.168.201.2, lago-basic-suite-master-host0, res: False
> >> (sslutils:244)
> >> 2017-04-30 14:23:35,678-0400 ERROR (Reactor thread)
> >> [ProtocolDetector.SSLHandshakeDispatcher] peer certificate does not
> >> match host name (sslutils:226)
> >>
> >> It looks like the engine issued certificate for
> >> 'lago-basic-suite-master-host0' but we resolve 192.168.201.2 to
> >> 'lago-basic-suite-master-host0.lago.local'.
> >> Can we fix it as well?
> >>
> >> Thanks,
> >> Piotr
> >>
> >> On Sun, Apr 30, 2017 at 7:42 PM, Piotr Kliczewski <pklic...@redhat.com>
> >> wrote:
> >> > Wow, great.
> >> >
> >> > Thank you!
> >> >
> >> > 30 kwi 2017 19:40 "Nadav Goldin" <ngol...@redhat.com> napisał(a):
> >> >>
> >> >> Ok, I think the issue was the unqualified domain name. The
> certificate
> >> >> was generated(as before for 'engine') without the domain name, i.e.
> >> >> 'lago-basic-suite-master-engine', on VDSM side it resolved the IP to
> >> >> the address 'lago-basic-suite-master-engine.lago.local' and then
> >> >> failed comparing it to the unqualified one. I assume this is the
> >> >> expected behaviour, though not sure(as you can easily resolve
> >> >> 'lago-basic-suite-master-engine' to
> >> >> 'lago-basic-suite-master-engine.lago.local' on the hosts). It should
> >> >> be fixed in [1], just ran OST manual with the same debugging patch
> >> >> applied on top of yours, and at least add_hosts passed.
> >> >>
> >> >>
> >> >> [1] https://gerrit.ovirt.org/#/c/76225/10
> >> >> [2] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/338/
> console
> >> >>
> >> >> On Sun, Apr 30, 2017 at 7:50 PM, Piotr Kliczewski <
> pklic...@redhat.com>
> >> >> wrote:
> >> >> > Sure, will take look later today.
> >> >> >
> >> >> > 30 kwi 2017 18:47 "Nadav Goldin" <ngol...@redhat.com> napisał(a):
> >> >> >>
> >> >> >> Thanks for the explanation.
> >> >> >>
> >> >> >> I added some more debugging messages on top of your patch, could
> you
> >> >> >> please take a look at [1] and tell me what do you expect to
> resolve
> >> >> >> differently for this to work?
> >> >> >>
> >> >> >>
> >> >> >> [1]
> >> >> >>
> >> >> >>
> >> >> >> http://jenkins.ovirt.org/job/ovirt-system-tests_manual/337/
> artifact/exported-artifacts/test_logs/basic-suite-master/
> post-002_bootstrap.py/lago-basic-suite-master-host0/_var_log/vdsm/vdsm.log
> >
> >
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 27-04-2017 ] [add_hosts]

[Piotr Kliczewski]

I think it depends on which name we use when we add a host to the engine.
We need to be consistent and use the same host name when adding a host and
a fqdn for the host ip.

On Sun, Apr 30, 2017 at 9:34 PM, Piotr Kliczewski <
piotr.kliczew...@gmail.com> wrote:

> Nadav,
>
> Thank you for working on this but we have one more issue with name
> resolution.
>
> I checked the last job you triggered and I noticed that vm migration
> failed due to similar issue between the hosts.
> Here is a piece of custom logs that you added:
>
> 2017-04-30 14:23:35,675-0400 INFO  (Reactor thread)
> [ProtocolDetector.SSLHandshakeDispatcher] subject:
> ((('organizationName', u'Test'),), (('commonName',
> u'lago-basic-suite-master-host0'),)), key: organizationName, value:
> Test (sslutils:241)
> 2017-04-30 14:23:35,675-0400 INFO  (Reactor thread)
> [ProtocolDetector.SSLHandshakeDispatcher] subject:
> ((('organizationName', u'Test'),), (('commonName',
> u'lago-basic-suite-master-host0'),)), key: commonName, value:
> lago-basic-suite-master-host0 (sslutils:241)
> 2017-04-30 14:23:35,676-0400 INFO  (Reactor thread)
> [ProtocolDetector.SSLHandshakeDispatcher] src_addr:
> :::192.168.201.2, cn_addr: lago-basic-suite-master-host0
> (sslutils:262)
> 2017-04-30 14:23:35,676-0400 INFO  (Reactor thread)
> [ProtocolDetector.SSLHandshakeDispatcher] src_addr_extracted:
> 192.168.201.2, cn_addr_extracted: lago-basic-suite-master-host0
> (sslutils:266)
> 2017-04-30 14:23:35,677-0400 INFO  (Reactor thread)
> [ProtocolDetector.SSLHandshakeDispatcher]
> socket.gethostbyadd(src_addr)[0]:
> lago-basic-suite-master-host0.lago.local (sslutils:268)
> 2017-04-30 14:23:35,678-0400 INFO  (Reactor thread)
> [ProtocolDetector.SSLHandshakeDispatcher] compare
> :::192.168.201.2, lago-basic-suite-master-host0, res: False
> (sslutils:244)
> 2017-04-30 14:23:35,678-0400 ERROR (Reactor thread)
> [ProtocolDetector.SSLHandshakeDispatcher] peer certificate does not
> match host name (sslutils:226)
>
> It looks like the engine issued certificate for
> 'lago-basic-suite-master-host0' but we resolve 192.168.201.2 to
> 'lago-basic-suite-master-host0.lago.local'.
> Can we fix it as well?
>
> Thanks,
> Piotr
>
> On Sun, Apr 30, 2017 at 7:42 PM, Piotr Kliczewski <pklic...@redhat.com>
> wrote:
> > Wow, great.
> >
> > Thank you!
> >
> > 30 kwi 2017 19:40 "Nadav Goldin" <ngol...@redhat.com> napisał(a):
> >>
> >> Ok, I think the issue was the unqualified domain name. The certificate
> >> was generated(as before for 'engine') without the domain name, i.e.
> >> 'lago-basic-suite-master-engine', on VDSM side it resolved the IP to
> >> the address 'lago-basic-suite-master-engine.lago.local' and then
> >> failed comparing it to the unqualified one. I assume this is the
> >> expected behaviour, though not sure(as you can easily resolve
> >> 'lago-basic-suite-master-engine' to
> >> 'lago-basic-suite-master-engine.lago.local' on the hosts). It should
> >> be fixed in [1], just ran OST manual with the same debugging patch
> >> applied on top of yours, and at least add_hosts passed.
> >>
> >>
> >> [1] https://gerrit.ovirt.org/#/c/76225/10
> >> [2] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/338/console
> >>
> >> On Sun, Apr 30, 2017 at 7:50 PM, Piotr Kliczewski <pklic...@redhat.com>
> >> wrote:
> >> > Sure, will take look later today.
> >> >
> >> > 30 kwi 2017 18:47 "Nadav Goldin" <ngol...@redhat.com> napisał(a):
> >> >>
> >> >> Thanks for the explanation.
> >> >>
> >> >> I added some more debugging messages on top of your patch, could you
> >> >> please take a look at [1] and tell me what do you expect to resolve
> >> >> differently for this to work?
> >> >>
> >> >>
> >> >> [1]
> >> >>
> >> >> http://jenkins.ovirt.org/job/ovirt-system-tests_manual/337/
> artifact/exported-artifacts/test_logs/basic-suite-master/
> post-002_bootstrap.py/lago-basic-suite-master-host0/_var_log/vdsm/vdsm.log
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt master ] [ 27-04-2017 ] [add_hosts]

[Piotr Kliczewski]

Nadav,

Thank you for working on this but we have one more issue with name resolution.

I checked the last job you triggered and I noticed that vm migration
failed due to similar issue between the hosts.
Here is a piece of custom logs that you added:

2017-04-30 14:23:35,675-0400 INFO  (Reactor thread)
[ProtocolDetector.SSLHandshakeDispatcher] subject:
((('organizationName', u'Test'),), (('commonName',
u'lago-basic-suite-master-host0'),)), key: organizationName, value:
Test (sslutils:241)
2017-04-30 14:23:35,675-0400 INFO  (Reactor thread)
[ProtocolDetector.SSLHandshakeDispatcher] subject:
((('organizationName', u'Test'),), (('commonName',
u'lago-basic-suite-master-host0'),)), key: commonName, value:
lago-basic-suite-master-host0 (sslutils:241)
2017-04-30 14:23:35,676-0400 INFO  (Reactor thread)
[ProtocolDetector.SSLHandshakeDispatcher] src_addr:
:::192.168.201.2, cn_addr: lago-basic-suite-master-host0
(sslutils:262)
2017-04-30 14:23:35,676-0400 INFO  (Reactor thread)
[ProtocolDetector.SSLHandshakeDispatcher] src_addr_extracted:
192.168.201.2, cn_addr_extracted: lago-basic-suite-master-host0
(sslutils:266)
2017-04-30 14:23:35,677-0400 INFO  (Reactor thread)
[ProtocolDetector.SSLHandshakeDispatcher]
socket.gethostbyadd(src_addr)[0]:
lago-basic-suite-master-host0.lago.local (sslutils:268)
2017-04-30 14:23:35,678-0400 INFO  (Reactor thread)
[ProtocolDetector.SSLHandshakeDispatcher] compare
:::192.168.201.2, lago-basic-suite-master-host0, res: False
(sslutils:244)
2017-04-30 14:23:35,678-0400 ERROR (Reactor thread)
[ProtocolDetector.SSLHandshakeDispatcher] peer certificate does not
match host name (sslutils:226)

It looks like the engine issued certificate for
'lago-basic-suite-master-host0' but we resolve 192.168.201.2 to
'lago-basic-suite-master-host0.lago.local'.
Can we fix it as well?

Thanks,
Piotr

On Sun, Apr 30, 2017 at 7:42 PM, Piotr Kliczewski <pklic...@redhat.com> wrote:
> Wow, great.
>
> Thank you!
>
> 30 kwi 2017 19:40 "Nadav Goldin" <ngol...@redhat.com> napisał(a):
>>
>> Ok, I think the issue was the unqualified domain name. The certificate
>> was generated(as before for 'engine') without the domain name, i.e.
>> 'lago-basic-suite-master-engine', on VDSM side it resolved the IP to
>> the address 'lago-basic-suite-master-engine.lago.local' and then
>> failed comparing it to the unqualified one. I assume this is the
>> expected behaviour, though not sure(as you can easily resolve
>> 'lago-basic-suite-master-engine' to
>> 'lago-basic-suite-master-engine.lago.local' on the hosts). It should
>> be fixed in [1], just ran OST manual with the same debugging patch
>> applied on top of yours, and at least add_hosts passed.
>>
>>
>> [1] https://gerrit.ovirt.org/#/c/76225/10
>> [2] http://jenkins.ovirt.org/job/ovirt-system-tests_manual/338/console
>>
>> On Sun, Apr 30, 2017 at 7:50 PM, Piotr Kliczewski <pklic...@redhat.com>
>> wrote:
>> > Sure, will take look later today.
>> >
>> > 30 kwi 2017 18:47 "Nadav Goldin" <ngol...@redhat.com> napisał(a):
>> >>
>> >> Thanks for the explanation.
>> >>
>> >> I added some more debugging messages on top of your patch, could you
>> >> please take a look at [1] and tell me what do you expect to resolve
>> >> differently for this to work?
>> >>
>> >>
>> >> [1]
>> >>
>> >> http://jenkins.ovirt.org/job/ovirt-system-tests_manual/337/artifact/exported-artifacts/test_logs/basic-suite-master/post-002_bootstrap.py/lago-basic-suite-master-host0/_var_log/vdsm/vdsm.log
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel