Open Stack

On 12/30/2013 6:21 AM, Michael Still wrote:
> Hi.
>
> The purpose of this email to is apologise for some incorrect -1 review
> scores which turbo hipster sent out today. I think its important when
> a third party testing tool is new to not have flakey results as people
> learn to trust the tool, so I want to explain what happened here.
>
> Turbo hipster is a system which takes nova code reviews, and runs
> database upgrades against them to ensure that we can still upgrade for
> users in the wild. It uses real user datasets, and also times
> migrations and warns when they are too slow for large deployments. It
> started voting on gerrit in the last week.
>
> Turbo hipster uses zuul to learn about reviews in gerrit that it
> should test. We run our own zuul instance, which talks to the
> openstack.org zuul instance. This then hands out work to our pool of
> testing workers. Another thing zuul does is it handles maintaining a
> git repository for the workers to clone from.
>
> This is where things went wrong today. For reasons I can't currently
> explain, the git repo on our zuul instance ended up in a bad state (it
> had a patch merged to master which wasn't in fact merged upstream
> yet). As this code is stock zuul from openstack-infra, I have a
> concern this might be a bug that other zuul users will see as well.
>
> I've corrected the problem for now, and kicked off a recheck of any
> patch with a -1 review score from turbo hipster in the last 24 hours.
> I'll talk to the zuul maintainers tomorrow about the git problem and
> see what we can learn.
>
> Thanks heaps for your patience.
>
> Michael
>

How do I interpret the warning and -1 from turbo-hipster on my patch 
here [1] with the logs here [2]?

I'm inclined to just do 'recheck migrations' on this since this patch 
doesn't have anything to do with this -1 as far as I can tell.

[1] https://review.openstack.org/#/c/64725/4/
[2] 
https://ssl.rcbops.com/turbo_hipster/logviewer/?q=/turbo_hipster/results/64/64725/4/check/gate-real-db-upgrade_nova_mysql_user_001/5186e53/user_001.log

-- 

Thanks,

Matt Riedemann