Re: [ovirt-devel] The importance of fixing failed build-artifacts jobs

[Martin Perina]

On Thu, Feb 22, 2018 at 8:41 PM, Yaniv Kaul  wrote:

> I think there's a rush to add FC27 and S390 (unrelated?) to the build. If
> either fail, right now, I don't think we should be too concerned with them.
> In the very near future we should be, though.
> Y.
>
> On Thu, Feb 22, 2018 at 9:06 PM, Dafna Ron  wrote:
>
>> Hi All,
>>
>> We have been seeing a large amount of changes that are not deployed into
>> tested lately because of failed build-artifacts jobs so we decided that
>> perhaps we need to explain the importance of fixing a failed
>> build-artifacts job.
>>
>> If a change failed a build-artifacts job, no matter what platform/arch it
>> failed in, the change will not be deployed to tested.
>>
>> Here is an example of a change that will not be added to tested:
>>
>> [image: Inline image 1]
>>
>> As you can see, only one of the build-artifacts jobs failed but since the
>> project specify that it requires all of these arches/platforms, the change
>> will not be added to tested until all of the jobs are fixed.
>>
>
​Is there a way how to identify the distribution as "not mandatory"? I mean
we want the build, but it fails it should not affect the whole flow. That
would really help with fcraw issues, because it's expected that things will
often be broken there​ ...


>> So what can we do?
>>
>> 1. Add the code which builds-artifacts to 'check-patch' so you'll get a
>> -1 if a build failed (assuming you will not merge with -1 from CI).
>> 2. post merge - look for emails on failed artifacts on your change (you
>> will have to fix the job and then re-trigger the change)
>> 3. you can see all current broken failed artifacts jobs in jenkins under
>> 'unstable critical' view [1] and you will know if your project is being
>> deployed.
>> 4. Remove the broken OS from your project ( either from Jenkins or from
>> your automation dir if you're using V2 ) - ask us for help! this should be
>> an easy patch
>> 5.Don't add new OS builds until you're absolutly sure they work ( you can
>> add check-patch to keep testing it, but don't add build-artifacts until its
>> stable ).
>>
>> Please contact myself or anyone else from the CI team for assistance or
>> questions and we would be happy to help.
>>
>> [1] http://jenkins.ovirt.org/
>>
>> Thank you,
>>
>> Dafna
>>
>>
>>
>>
>>
>>
>> ___
>> 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
>



-- 
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] The importance of fixing failed build-artifacts jobs

[Yaniv Kaul]

I think there's a rush to add FC27 and S390 (unrelated?) to the build. If
either fail, right now, I don't think we should be too concerned with them.
In the very near future we should be, though.
Y.

On Thu, Feb 22, 2018 at 9:06 PM, Dafna Ron  wrote:

> Hi All,
>
> We have been seeing a large amount of changes that are not deployed into
> tested lately because of failed build-artifacts jobs so we decided that
> perhaps we need to explain the importance of fixing a failed
> build-artifacts job.
>
> If a change failed a build-artifacts job, no matter what platform/arch it
> failed in, the change will not be deployed to tested.
>
> Here is an example of a change that will not be added to tested:
>
> [image: Inline image 1]
>
> As you can see, only one of the build-artifacts jobs failed but since the
> project specify that it requires all of these arches/platforms, the change
> will not be added to tested until all of the jobs are fixed.
>
> So what can we do?
>
> 1. Add the code which builds-artifacts to 'check-patch' so you'll get a -1
> if a build failed (assuming you will not merge with -1 from CI).
> 2. post merge - look for emails on failed artifacts on your change (you
> will have to fix the job and then re-trigger the change)
> 3. you can see all current broken failed artifacts jobs in jenkins under
> 'unstable critical' view [1] and you will know if your project is being
> deployed.
> 4. Remove the broken OS from your project ( either from Jenkins or from
> your automation dir if you're using V2 ) - ask us for help! this should be
> an easy patch
> 5.Don't add new OS builds until you're absolutly sure they work ( you can
> add check-patch to keep testing it, but don't add build-artifacts until its
> stable ).
>
> Please contact myself or anyone else from the CI team for assistance or
> questions and we would be happy to help.
>
> [1] http://jenkins.ovirt.org/
>
> Thank you,
>
> Dafna
>
>
>
>
>
>
> ___
> 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 (vdsm) ] [ 22-02-2018 ] [ 002_bootstrap.verify_add_hosts + 002_bootstrap.add_hosts ]

[Dafna Ron]

Thanks Dan!


On Thu, Feb 22, 2018 at 7:15 PM, Dan Kenigsberg  wrote:

> On Thu, Feb 22, 2018 at 12:59 PM, Dafna Ron  wrote:
> > Hi,
> >
> > We had two failed tests reported in vdsm project last evening  the patch
> > reported seems to be related to the issue.
> >
> >
> > Link and headline of suspected patches:
> >
> > momIF: change the way we connect to MOM -
> > https://gerrit.ovirt.org/#/c/87944/
> >
> >
> > Link to Job:
> >
> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5823/
> >
> > Link to all logs:
> >
> > http://jenkins.ovirt.org/job/ovirt-master_change-queue-
> tester/5823/artifacts
> >
> > (Relevant) error snippet from the log:
> >
> > 
> >
> >
> >
> > 2018-02-21 14:15:47,576-0500 INFO  (MainThread) [vdsm.api] FINISH
> > prepareForShutdown return=None from=internal,
> > task_id=7d37a33b-0215-40c0-a821-9b94707caca6 (api:52)
> > 2018-02-21 14:15:47,576-0500 ERROR (MainThread) [vds] Exception raised
> > (vdsmd:158)
> > Traceback (most recent call last):
> >   File "/usr/lib/python2.7/site-packages/vdsm/vdsmd.py", line 156, in
> run
> > serve_clients(log)
> >   File "/usr/lib/python2.7/site-packages/vdsm/vdsmd.py", line 103, in
> > serve_clients
> > cif = clientIF.getInstance(irs, log, scheduler)
> >   File "/usr/lib/python2.7/site-packages/vdsm/clientIF.py", line 251, in
> > getInstance
> > cls._instance = clientIF(irs, log, scheduler)
> >   File "/usr/lib/python2.7/site-packages/vdsm/clientIF.py", line 121, in
> > __init__
> > self.mom = MomClient(config.get("mom", "socket_path"))
> >   File "/usr/lib/python2.7/site-packages/vdsm/momIF.py", line 51, in
> > __init__
> > raise MomNotAvailableError()
> > MomNotAvailableError
> >
> > 
> >
>
> this smells like a race between mom and vdsm startups (that
> bidirectional dependency is woderful!). I am sure that Francesco can
> fix it quickly, but until then I've posted a revert of the offending
> patch
> http://jenkins.ovirt.org/job/ovirt-system-tests_manual/2225/
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

Re: [ovirt-devel] [ OST Failure Report ] [ oVirt Master (vdsm) ] [ 22-02-2018 ] [ 002_bootstrap.verify_add_hosts + 002_bootstrap.add_hosts ]

[Dan Kenigsberg]

On Thu, Feb 22, 2018 at 12:59 PM, Dafna Ron  wrote:
> Hi,
>
> We had two failed tests reported in vdsm project last evening  the patch
> reported seems to be related to the issue.
>
>
> Link and headline of suspected patches:
>
> momIF: change the way we connect to MOM -
> https://gerrit.ovirt.org/#/c/87944/
>
>
> Link to Job:
>
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5823/
>
> Link to all logs:
>
> http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5823/artifacts
>
> (Relevant) error snippet from the log:
>
> 
>
>
>
> 2018-02-21 14:15:47,576-0500 INFO  (MainThread) [vdsm.api] FINISH
> prepareForShutdown return=None from=internal,
> task_id=7d37a33b-0215-40c0-a821-9b94707caca6 (api:52)
> 2018-02-21 14:15:47,576-0500 ERROR (MainThread) [vds] Exception raised
> (vdsmd:158)
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/vdsm/vdsmd.py", line 156, in run
> serve_clients(log)
>   File "/usr/lib/python2.7/site-packages/vdsm/vdsmd.py", line 103, in
> serve_clients
> cif = clientIF.getInstance(irs, log, scheduler)
>   File "/usr/lib/python2.7/site-packages/vdsm/clientIF.py", line 251, in
> getInstance
> cls._instance = clientIF(irs, log, scheduler)
>   File "/usr/lib/python2.7/site-packages/vdsm/clientIF.py", line 121, in
> __init__
> self.mom = MomClient(config.get("mom", "socket_path"))
>   File "/usr/lib/python2.7/site-packages/vdsm/momIF.py", line 51, in
> __init__
> raise MomNotAvailableError()
> MomNotAvailableError
>
> 
>

this smells like a race between mom and vdsm startups (that
bidirectional dependency is woderful!). I am sure that Francesco can
fix it quickly, but until then I've posted a revert of the offending
patch
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/2225/
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] The importance of fixing failed build-artifacts jobs

[Dafna Ron]

Hi All,

We have been seeing a large amount of changes that are not deployed into
tested lately because of failed build-artifacts jobs so we decided that
perhaps we need to explain the importance of fixing a failed
build-artifacts job.

If a change failed a build-artifacts job, no matter what platform/arch it
failed in, the change will not be deployed to tested.

Here is an example of a change that will not be added to tested:

[image: Inline image 1]

As you can see, only one of the build-artifacts jobs failed but since the
project specify that it requires all of these arches/platforms, the change
will not be added to tested until all of the jobs are fixed.

So what can we do?

1. Add the code which builds-artifacts to 'check-patch' so you'll get a -1
if a build failed (assuming you will not merge with -1 from CI).
2. post merge - look for emails on failed artifacts on your change (you
will have to fix the job and then re-trigger the change)
3. you can see all current broken failed artifacts jobs in jenkins under
'unstable critical' view [1] and you will know if your project is being
deployed.
4. Remove the broken OS from your project ( either from Jenkins or from
your automation dir if you're using V2 ) - ask us for help! this should be
an easy patch
5.Don't add new OS builds until you're absolutly sure they work ( you can
add check-patch to keep testing it, but don't add build-artifacts until its
stable ).

Please contact myself or anyone else from the CI team for assistance or
questions and we would be happy to help.

[1] http://jenkins.ovirt.org/

Thank you,

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

[ovirt-devel] Let's get oVirt in Stack Overflow's Open Source Advertising again

[Allon Mureinik]

Hi all,

With Eldan's help, we have an advert for oVirt [1] suggested on Stack
Overflow's traditional Open Source Advertising campaign [2].

Like always, we need the upvotes to get it up there.

Want to see oVirt on Stack Overflow's sidebar again? Hope over and upvote.


-Allon

[1] https://meta.stackoverflow.com/a/363689/2422776
[2] https://meta.stackoverflow.com/q/362773/2422776
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

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

[Sandro Bonazzola]

2018-02-22 14:45 GMT+01:00 Michal Skrivanek :

>
>
> On 22 Feb 2018, at 10:10, Edward Haas  wrote:
>
> Hello,
>
> VDSM check-patch on master started to fail, looks like some repos vanished.
>
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-
> x86_64/21853/console
>
> Can someone have a look? (Do we need ppc64?
>
>
> you’re referring to ppc64le I suppose (as per the log). Not to be confused
> with ppc64 (big endian).
> And yes we need it, it’s one of the supported platforms and everyone is
> supposed to verify their stuff on ppc64le in addition to x86_64;)
>

>From today #centos-devel IRC channel:

(11:09:18) sbonazzo: Arrfab: hi, looks like something broke yesterday
https://cbs.centos.org/repos/virt7-ovirt-common-testing/ now is x86_64 only
while 2 days ago it also had aarch64 and ppc64le
(11:09:26) sbonazzo: Arrfab: can you have a look?
(11:52:56) Arrfab: sbonazzo: sorry, in meeting but alphacc can probably
have a look (as he submitted a patch for mash yesterday)
(11:53:35) sbonazzo: alphacc: ^ (11:09:18) sbonazzo: Arrfab: hi, looks like
something broke yesterday
https://cbs.centos.org/repos/virt7-ovirt-common-testing/ now is x86_64 only
while 2 days ago it also had aarch64 and ppc64le
(13:40:38) alphacc: sbonazzo: I am checking
(14:13:58) alphacc: sbonazzo: it will recover in ~10 minutes
(14:15:38) sbonazzo: alphacc: thanks

Repositories are back to normal state.

As a side note, please avoid to use
https://cbs.centos.org/repos/virt7-ovirt-common-testing/$basearch
Please use https://buildlogs.centos.org/centos/7/virt/$basearch/ovirt-4.2/
instead.


>
> Thanks,
> michal
>
> Why it was removed?)
>
> Thanks,
> Edy.
> ___
> 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
>



-- 

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] [VDSM] Failing CI check-patch on master, el7: Missing ppc64 repos

[Michal Skrivanek]

> On 22 Feb 2018, at 10:10, Edward Haas  wrote:
> 
> Hello,
> 
> VDSM check-patch on master started to fail, looks like some repos vanished.
> 
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/21853/console 
> 
> 
> Can someone have a look? (Do we need ppc64?

you’re referring to ppc64le I suppose (as per the log). Not to be confused with 
ppc64 (big endian).
And yes we need it, it’s one of the supported platforms and everyone is 
supposed to verify their stuff on ppc64le in addition to x86_64;)

Thanks,
michal

> Why it was removed?)
> 
> Thanks,
> Edy.
> ___
> 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 (ovirt-engine-metrics) ] [ 22-02-2018 ] [ 003_00_metrics_bootstrap.metrics_and_log_collector ]

[Yaniv Kaul]

On Thu, Feb 22, 2018 at 2:46 PM, Dafna Ron  wrote:

> hi,
>
> We are failing test 003_00_metrics_bootstrap.metrics_and_log_collector
> for basic suite.
>
> *Link and headline of suspected patches: *
>
>
>
>
>
>
> *ansible: End playbook based on initial validations -
> https://gerrit.ovirt.org/#/c/88062/
> Link to
> Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5829/
> Link
> to all
> logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5829/artifacts
> (Relevant)
> error snippet from the log: *
>
> /var/tmp:
> drwxr-x--x. root abrt system_u:object_r:abrt_var_cache_t:s0 abrt
> -rw---. root root unconfined_u:object_r:user_tmp_t:s0 rpm-tmp.aLitM7
> -rw---. root root unconfined_u:object_r:user_tmp_t:s0 rpm-tmp.G2r7IM
> -rw---. root root unconfined_u:object_r:user_tmp_t:s0 rpm-tmp.kVymZE
> -rw---. root root unconfined_u:object_r:user_tmp_t:s0 rpm-tmp.uPDvvU
> drwx--. root root system_u:object_r:tmp_t:s0   
> systemd-private-cd49c74726d5463f8d6f6502380e5e12-chronyd.service-i1T5IE
> drwx--. root root system_u:object_r:tmp_t:s0   
> systemd-private-cd49c74726d5463f8d6f6502380e5e12-systemd-timedated.service-lhoUsS
>
> /var/tmp/abrt:
> -rw---. root root system_u:object_r:abrt_var_cache_t:s0 last-via-server
>
> /var/tmp/systemd-private-cd49c74726d5463f8d6f6502380e5e12-chronyd.service-i1T5IE:
> drwxrwxrwt. root root system_u:object_r:tmp_t:s0   tmp
>
> /var/tmp/systemd-private-cd49c74726d5463f8d6f6502380e5e12-chronyd.service-i1T5IE/tmp:
>
> /var/tmp/systemd-private-cd49c74726d5463f8d6f6502380e5e12-systemd-timedated.service-lhoUsS:
> drwxrwxrwt. root root system_u:object_r:tmp_t:s0   tmp
>
> /var/tmp/systemd-private-cd49c74726d5463f8d6f6502380e5e12-systemd-timedated.service-lhoUsS/tmp:
>
> /var/yp:
> )
> 2018-02-22 07:24:05::DEBUG::__main__::251::root:: STDERR(/bin/ls: cannot open 
> directory 
> /rhev/data-center/mnt/blockSD/6babba93-09c8-4846-9ccb-07728f72eecb/master/tasks/bd563276-5092-4d28-86c4-63aa6c0b4344.temp:
>  No such file or directory
> )
> 2018-02-22 07:24:05::ERROR::__main__::832::root:: Failed to collect logs 
> from: lago-basic-suite-master-host-0; /bin/ls: cannot open directory 
> /rhev/data-center/mnt/blockSD/6babba93-09c8-4846-9ccb-07728f72eecb/master/tasks/bd563276-5092-4d28-86c4-63aa6c0b4344.temp:
>  No such file or directory
>
>
Is that reproducible? It's a log collector bug anyway, but I assume it's a
race between some task (for example, downloading images from Glance) and
log collector collecting logs.
Can you open a bug on log collector?
TIA,
Y.


>
> **
>
> ___
> 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] [ OST Failure Report ] [ oVirt Master (ovirt-engine-metrics) ] [ 22-02-2018 ] [ 003_00_metrics_bootstrap.metrics_and_log_collector ]

[Dafna Ron]

hi,

We are failing test 003_00_metrics_bootstrap.metrics_and_log_collector for
basic suite.

*Link and headline of suspected patches: *






*ansible: End playbook based on initial validations -
https://gerrit.ovirt.org/#/c/88062/
Link to
Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5829/
Link
to all
logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5829/artifacts
(Relevant)
error snippet from the log: *

/var/tmp:
drwxr-x--x. root abrt system_u:object_r:abrt_var_cache_t:s0 abrt
-rw---. root root unconfined_u:object_r:user_tmp_t:s0 rpm-tmp.aLitM7
-rw---. root root unconfined_u:object_r:user_tmp_t:s0 rpm-tmp.G2r7IM
-rw---. root root unconfined_u:object_r:user_tmp_t:s0 rpm-tmp.kVymZE
-rw---. root root unconfined_u:object_r:user_tmp_t:s0 rpm-tmp.uPDvvU
drwx--. root root system_u:object_r:tmp_t:s0
systemd-private-cd49c74726d5463f8d6f6502380e5e12-chronyd.service-i1T5IE
drwx--. root root system_u:object_r:tmp_t:s0
systemd-private-cd49c74726d5463f8d6f6502380e5e12-systemd-timedated.service-lhoUsS

/var/tmp/abrt:
-rw---. root root system_u:object_r:abrt_var_cache_t:s0 last-via-server

/var/tmp/systemd-private-cd49c74726d5463f8d6f6502380e5e12-chronyd.service-i1T5IE:
drwxrwxrwt. root root system_u:object_r:tmp_t:s0   tmp

/var/tmp/systemd-private-cd49c74726d5463f8d6f6502380e5e12-chronyd.service-i1T5IE/tmp:

/var/tmp/systemd-private-cd49c74726d5463f8d6f6502380e5e12-systemd-timedated.service-lhoUsS:
drwxrwxrwt. root root system_u:object_r:tmp_t:s0   tmp

/var/tmp/systemd-private-cd49c74726d5463f8d6f6502380e5e12-systemd-timedated.service-lhoUsS/tmp:

/var/yp:
)
2018-02-22 07:24:05::DEBUG::__main__::251::root:: STDERR(/bin/ls:
cannot open directory
/rhev/data-center/mnt/blockSD/6babba93-09c8-4846-9ccb-07728f72eecb/master/tasks/bd563276-5092-4d28-86c4-63aa6c0b4344.temp:
No such file or directory
)
2018-02-22 07:24:05::ERROR::__main__::832::root:: Failed to collect
logs from: lago-basic-suite-master-host-0; /bin/ls: cannot open
directory 
/rhev/data-center/mnt/blockSD/6babba93-09c8-4846-9ccb-07728f72eecb/master/tasks/bd563276-5092-4d28-86c4-63aa6c0b4344.temp:
No such file or directory


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

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

[Dan Kenigsberg]

On Thu, Feb 22, 2018 at 11:10 AM, Edward Haas  wrote:
> Hello,
>
> VDSM check-patch on master started to fail, looks like some repos vanished.
>
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/21853/console
>
> Can someone have a look? (Do we need ppc64? Why it was removed?)

a bit more context:

08:25:37 
https://cbs.centos.org/repos/virt7-ovirt-common-testing/ppc64le/os/repodata/repomd.xml:
[Errno 14] HTTPS Error 404 - Not Found

we need it when running tests on ppc. Unfortunately, CentOS does not
place its repo is the "standard" tree structure of os//packages

Sandro, do you know if the repo was moved to a new permanent location?
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

[ovirt-devel] [ OST Failure Report ] [ oVirt Master (ovirt-host) ] [ 22-02-2018 ] [002_bootstrap.add_hosts ]

[Dafna Ron]

hi,

we have a failed test for ovirt-host in upgrade suite.

*Link and headline of suspected patches: *






*Require collectd-virt plugin - https://gerrit.ovirt.org/#/c/87311/
Link to Job:
http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5827/
Link
to all
logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5827/artifacts
(Relevant)
error snippet from the log: *

2018-02-22 05:38:47,587-05 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(VdsDeploy) [546df98d] EVENT_ID: VDS_INSTALL_IN_PROGRESS(509),
Installing Host lago-upgrade-from-release-suite-master-host0. Setting
kernel arguments.
2018-02-22 05:38:47,858-05 ERROR
[org.ovirt.engine.core.uutils.ssh.SSHDialog]
(EE-ManagedThreadFactory-engine-Thread-1) [546df98d] Swallowing
exception as preferring stderr
2018-02-22 05:38:47,859-05 ERROR
[org.ovirt.engine.core.uutils.ssh.SSHDialog]
(EE-ManagedThreadFactory-engine-Thread-1) [546df98d] SSH error running
command root@lago-upgrade-from-release-suite-master-host0:'umask 0077;
MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t ovirt-XX)";
trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr
\"${MYTMP}\" > /dev/null 2>&1" 0; tar --warning=no-timestamp -C
"${MYTMP}" -x &&  "${MYTMP}"/ovirt-host-deploy
DIALOG/dialect=str:machine DIALOG/customization=bool:True':
RuntimeException: Unexpected error during execution: bash: line 1:
1395 Segmentation fault  "${MYTMP}"/ovirt-host-deploy
DIALOG/dialect=str:machine DIALOG/customization=bool:True

2018-02-22 05:38:47,859-05 ERROR
[org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase] (VdsDeploy)
[546df98d] Error during deploy dialog
2018-02-22 05:38:47,860-05 ERROR
[org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase]
(EE-ManagedThreadFactory-engine-Thread-1) [546df98d] Error during host
lago-upgrade-from-release-suite-master-host0 install
2018-02-22 05:38:47,864-05 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-engine-Thread-1) [546df98d] EVENT_ID:
VDS_INSTALL_IN_PROGRESS_ERROR(511), An error has occurred during
installation of Host lago-upgrade-from-release-suite-master-host0:
Unexpected error during execution: bash: line 1:  1395 Segmentation
fault  "${MYTMP}"/ovirt-host-deploy DIALOG/dialect=str:machine
DIALOG/customization=bool:True
.
2018-02-22 05:38:47,864-05 ERROR
[org.ovirt.engine.core.bll.hostdeploy.VdsDeployBase]
(EE-ManagedThreadFactory-engine-Thread-1) [546df98d] Error during host
lago-upgrade-from-release-suite-master-host0 install, preferring first
exception: Unexpected connection termination
2018-02-22 05:38:47,864-05 ERROR
[org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand]
(EE-ManagedThreadFactory-engine-Thread-1) [546df98d] Host installation
failed for host '65c048e5-a97a-422d-88b8-abe1fd925602',
'lago-upgrade-from-release-suite-master-host0': Unexpected connection
termination
2018-02-22 05:38:47,869-05 INFO
[org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-1) [546df98d] START,
SetVdsStatusVDSCommand(HostName =
lago-upgrade-from-release-suite-master-host0,
SetVdsStatusVDSCommandParameters:{hostId='65c048e5-a97a-422d-88b8-abe1fd925602',
status='InstallFailed', nonOperationalReason='NONE',
stopSpmFailureLogged='false', maintenanceReason='null'}), log id:
1973b09c
2018-02-22 05:38:47,898-05 INFO
[org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-1) [546df98d] FINISH,
SetVdsStatusVDSCommand, log id: 1973b09c
2018-02-22 05:38:47,911-05 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-engine-Thread-1) [546df98d] EVENT_ID:
VDS_INSTALL_FAILED(505), Host
lago-upgrade-from-release-suite-master-host0 installation failed.
Unexpected connection termination.
2018-02-22 05:38:47,920-05 INFO
[org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand]
(EE-ManagedThreadFactory-engine-Thread-1) [546df98d] Lock freed to
object 'EngineLock:{exclusiveLocks='[65c048e5-a97a-422d-88b8-abe1fd925602=VDS]',
sharedLocks=''}'

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

[ovirt-devel] [ OST Failure Report ] [ oVirt Master (vdsm) ] [ 22-02-2018 ] [ 002_bootstrap.verify_add_hosts + 002_bootstrap.add_hosts ]

[Dafna Ron]

Hi,

We had two failed tests reported in vdsm project last evening  the patch
reported seems to be related to the issue.









*Link and headline of suspected patches: momIF: change the way we connect
to MOM - https://gerrit.ovirt.org/#/c/87944/
Link to
Job:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5823/
Link
to all
logs:http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/5823/artifacts
(Relevant)
error snippet from the log: *

2018-02-21 14:15:47,576-0500 INFO  (MainThread) [vdsm.api] FINISH
prepareForShutdown return=None from=internal,
task_id=7d37a33b-0215-40c0-a821-9b94707caca6 (api:52)
2018-02-21 14:15:47,576-0500 ERROR (MainThread) [vds] Exception raised
(vdsmd:158)
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/vdsmd.py", line 156, in run
serve_clients(log)
  File "/usr/lib/python2.7/site-packages/vdsm/vdsmd.py", line 103, in
serve_clients
cif = clientIF.getInstance(irs, log, scheduler)
  File "/usr/lib/python2.7/site-packages/vdsm/clientIF.py", line 251,
in getInstance
cls._instance = clientIF(irs, log, scheduler)
  File "/usr/lib/python2.7/site-packages/vdsm/clientIF.py", line 121,
in __init__
self.mom = MomClient(config.get("mom", "socket_path"))
  File "/usr/lib/python2.7/site-packages/vdsm/momIF.py", line 51, in __init__
raise MomNotAvailableError()
MomNotAvailableError

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

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

[Edward Haas]

Hello,

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

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

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

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