Open Stack

On Monday, January 27, 2014 7:17:27 AM, Alessandro Pilotti wrote:
> On 25 Jan 2014, at 16:51 , Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:
>
>>
>>
>> On 1/24/2014 3:41 PM, Peter Pouliot wrote:
>>> Hello OpenStack Community,
>>>
>>> I am excited at this opportunity to make the community aware that the
>>> Hyper-V CI infrastructure
>>>
>>> is now up and running.  Let’s first start with some housekeeping
>>> details.  Our Tempest logs are
>>>
>>> publically available here: http://64.119.130.115. You will see them show
>>> up in any
>>>
>>> Nova Gerrit commit from this moment on.
>>> <snip>
>>
>> So now some questions. :)
>>
>> I saw this failed on one of my nova patches [1].  It says the build succeeded but that the tests failed.  I talked with Alessandro about this yesterday and he said that's working as designed, something with how the scoring works with zuul?
>
> I spoke with clarkb on infra, since we were also very puzzled by this behaviour. I’ve been told that when the job is non voting, it’s always reported as succeeded, which makes sense, although sligltly misleading.
> The message in the Gerrit comment is clearly stating: "Test run failed in ..m ..s (non-voting)”, so this should be fair enough. It’d be great to have a way to get rid of the “Build succeded” message above.
>
>> The problem I'm having is figuring out why it failed.  I looked at the compute logs but didn't find any errors.  Can someone help me figure out what went wrong here?
>>
>
> The reason for the failure of this job can be found here:
>
> http://64.119.130.115/69047/1/devstack_logs/screen-n-api.log.gz
>
> Please search for "(1054, "Unknown column 'instances.locked_by' in 'field list'")"
>
> In this case the job failed when "nova service-list” got called to verify wether the compute nodes have been properly added to the devstack instance in the overcloud.
>
> During the weekend we added also a console.log to help in simplifying debugging, especially in the rare cases in which the job fails before getting to run tempest:
>
> http://64.119.130.115/69047/1/console.log.gz
>
>
> Let me know if this helps in tracking down your issue!
>
> Alessandro
>
>
>> [1] https://review.openstack.org/#/c/69047/1
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Alex, thanks, figured it out and yes, the console log is helpful, and 
the fail was a real bug in my patch which changed how the 180 migration 
was doing something which later broke another migration running against 
your MySQL backend - so nice catch.

--

Thanks,

Matt Riedemann