<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 27, 2017 at 12:53 PM, Dan Kenigsberg <span dir="ltr"><<a href="mailto:danken@redhat.com" target="_blank">danken@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Dec 27, 2017 at 12:34 PM, Barak Korren <<a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a>> wrote:<br>
> On 25 December 2017 at 14:14, Dan Kenigsberg <<a href="mailto:danken@redhat.com">danken@redhat.com</a>> wrote:<br>
>> On Mon, Dec 25, 2017 at 2:09 PM, Dominik Holler <<a href="mailto:dholler@redhat.com">dholler@redhat.com</a>> wrote:<br>
>>> A helpful hint is in<br>
>>><br>
>>> <a href="http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4492/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-098_ovirt_provider_ovn.py/lago-basic-suite-master-engine/_var_log/ovirt-engine/engine.log" rel="noreferrer" target="_blank">http://jenkins.ovirt.org/job/<wbr>ovirt-master_change-queue-<wbr>tester/4492/artifact/exported-<wbr>artifacts/basic-suit-master-<wbr>el7/test_logs/basic-suite-<wbr>master/post-098_ovirt_<wbr>provider_ovn.py/lago-basic-<wbr>suite-master-engine/_var_log/<wbr>ovirt-engine/engine.log</a> :<br>
>>> Caused by: org.jboss.resteasy.spi.<wbr>ReaderException: org.codehaus.jackson.map.<wbr>JsonMappingException: Can not construct instance of java.util.Calendar from String value '2017-12-27 13:19:51Z': not a valid representation (error: Can not parse date "2017-12-27 13:19:51Z": not compatible with any of standard forms ("yyyy-MM-dd'T'HH:mm:ss.SSSZ", "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'"<wbr>, "EEE, dd MMM yyyy HH:mm:ss zzz", "yyyy-MM-dd"))<br>
>>> at [Source: org.jboss.resteasy.client.<wbr>core.BaseClientResponse$<wbr>InputStreamWrapper@72c184c5; line: 1, column: 23] (through reference chain: com.woorea.openstack.keystone.<wbr>model.Access["token"]->com.<wbr>woorea.openstack.keystone.<wbr>model.Token["expires"])<br>
>>><br>
>>><br>
>>> This problem was introduced by<br>
>>> <a href="https://gerrit.ovirt.org/#/c/85702/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/<wbr>85702/</a><br>
>>><br>
>>> I created a fix:<br>
>>> <a href="https://gerrit.ovirt.org/85734" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/85734</a><br>
>><br>
>> Thanks for the quick fix.<br>
>><br>
>> Is the new format accpetable to other users of the keystone-like API<br>
>> (such at the neutron cli)?<br>
><br>
> It seems the fix patch itself failed as well:<br>
> <a href="http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4539/" rel="noreferrer" target="_blank">http://jenkins.ovirt.org/job/<wbr>ovirt-master_change-queue-<wbr>tester/4539/</a><br>
><br>
> The failed test is: 006_migrations.prepare_<wbr>migration_attachments_ipv6<br>
><br>
> It seems engine has lost the ability to talk to the host.<br>
><br>
> Logs are here:<br>
> <a href="http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4539/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-006_migrations.py/" rel="noreferrer" target="_blank">http://jenkins.ovirt.org/job/<wbr>ovirt-master_change-queue-<wbr>tester/4539/artifact/exported-<wbr>artifacts/basic-suit-master-<wbr>el7/test_logs/basic-suite-<wbr>master/post-006_migrations.py/</a><br>
<br>
</span>The error seems unrelated to the patch, since - as you say - the error<br>
is about host networking, long before OVN got involved.<br>
<br>
I see that<br>
<a href="http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/4539/artifact/exported-artifacts/basic-suit-master-el7/test_logs/basic-suite-master/post-006_migrations.py/lago-basic-suite-master-host-0/_var_log/vdsm/supervdsm.log/*view*/" rel="noreferrer" target="_blank">http://jenkins.ovirt.org/job/<wbr>ovirt-master_change-queue-<wbr>tester/4539/artifact/exported-<wbr>artifacts/basic-suit-master-<wbr>el7/test_logs/basic-suite-<wbr>master/post-006_migrations.py/<wbr>lago-basic-suite-master-host-<wbr>0/_var_log/vdsm/supervdsm.log/<wbr>*view*/</a><br>
<br>
has a worrying failure to ifup a bridge, which might be more related<br>
<br>
ifup/oncae8adf7ba944::ERROR::<wbr>2017-12-27<br>
05:03:06,001::concurrent::201:<wbr>:root::(run) FINISH thread<br>
<Thread(ifup/oncae8adf7ba944, started daemon 140108891563776)> failed<br>
Traceback (most recent call last):<br>
File "/usr/lib/python2.7/site-<wbr>packages/vdsm/common/<wbr>concurrent.py",<br>
line 194, in run<br>
ret = func(*args, **kwargs)<br>
File "/usr/lib/python2.7/site-<wbr>packages/vdsm/network/<wbr>configurators/ifcfg.py",<br>
line 925, in _exec_ifup<br>
_exec_ifup_by_name(<a href="http://iface.name" rel="noreferrer" target="_blank">iface.name</a>, cgroup)<br>
File "/usr/lib/python2.7/site-<wbr>packages/vdsm/network/<wbr>configurators/ifcfg.py",<br>
line 911, in _exec_ifup_by_name<br>
raise ConfigNetworkError(ERR_FAILED_<wbr>IFUP, out[-1] if out else '')<br>
ConfigNetworkError: (29, '\n')<br>
</blockquote></div><br></div><div class="gmail_extra">Does not seem to be a problem, it is an outcome of an ancient command on an device that does not exist anymore.<br></div><div class="gmail_extra">We are not cleaning up all the spawned threads at the end of a transaction, so we see such things from time to time.<br><br></div></div>