There's a versioning mess in ovirt-provider-ovn, which might cause theOn Thu, Dec 28, 2017 at 5:24 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
>
>
> On Dec 27, 2017 12:35 PM, "Barak Korren" <bkorren@redhat.com> wrote:
>
> On 25 December 2017 at 14:14, Dan Kenigsberg <danken@redhat.com> wrote:
>> On Mon, Dec 25, 2017 at 2:09 PM, Dominik Holler <dholler@redhat.com>
>> wrote:
>>> A helpful hint is in
>>>
>>>
>>> http://jenkins.ovirt.org/job/ovirt-master_change-queue- tester/4492/artifact/exported- artifacts/basic-suit-master- el7/test_logs/basic-suite- master/post-098_ovirt_ provider_ovn.py/lago-basic- suite-master-engine/_var_log/ ovirt-engine/engine.log
>>> :
>>> Caused by: org.jboss.resteasy.spi.ReaderException:
>>> org.codehaus.jackson.map.JsonMappingException: Can not construct instance of
>>> java.util.Calendar from String value '2017-12-27 13:19:51Z': not a valid
>>> representation (error: Can not parse date "2017-12-27 13:19:51Z": not
>>> compatible with any of standard forms ("yyyy-MM-dd'T'HH:mm:ss.SSSZ",
>>> "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", "EEE, dd MMM yyyy HH:mm:ss zzz",
>>> "yyyy-MM-dd"))
>>> at [Source:
>>> org.jboss.resteasy.client.core.BaseClientResponse$ InputStreamWrapper@72c184c5;
>>> line: 1, column: 23] (through reference chain:
>>> com.woorea.openstack.keystone.model.Access["token"]->com. woorea.openstack.keystone. model.Token["expires"])
>>>
>>>
>>> This problem was introduced by
>>> https://gerrit.ovirt.org/#/c/85702/
>>>
>>> I created a fix:
>>> https://gerrit.ovirt.org/85734
>>
>> Thanks for the quick fix.
>>
>> Is the new format accpetable to other users of the keystone-like API
>> (such at the neutron cli)?
>
> It seems the fix patch itself failed as well:
> http://jenkins.ovirt.org/job/ovirt-master_change-queue- tester/4539/
>
> The failed test is: 006_migrations.prepare_migration_attachments_ipv6
>
>
> Any updates on this failure?
fixed not to be tested. Fixing the master branch with
https://gerrit.ovirt.org/#/c/85797 (and possibly other patches) is our
utmost task for today.
Dan.