Open Stack

On 01/29/2014 11:10 PM, Matt Riedemann wrote:
>
>
> 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.

WOOT! I can't even tell you how excited I am that we're catching real 
bugs here. (honestly, if we weren't then all of this extra work we've 
put people through would be kinda depressing)