openstack-qa-team team mailing list archive

[Daryl Walleck <daryl.walleck@xxxxxxxxxxxxx>]

Hi Dan,

I've been reviewing the test failures from the gating job and what concerns me is that at least some of them are legitimate. They may not be caused by the patch at hand, but servers and volumes going into error status definitely signal issues, whether they be in code or environment. I don't have access to the Tempest CI environment so I don't have much insight into those issues specifically, though there might be some additional error checking that we can do to get more information on what is going wrong. 

I'm doing what I can Dan to get your patches reviewed. The trick being that since there is a dependency chain between most of the commits, it adds a level of complexity. Jay, who's done most of the CI setup thus far, is out of country, so I'm trying to find other folks I can reach out to help stabilize the environment.

Daryl

On Aug 21, 2012, at 3:17 PM, Dan Smith <danms@xxxxxxxxxx>
 wrote:

> Hi all,
> 
> I was just wondering if there's any reason to consider changing the gate
> requirement for getting patches into tempest to be roughly equivalent to
> nova (or the other components)? Right now, Nova patches get run against
> the tempest smoke tests, but could potentially break other tests in
> tempest that are required for future patches.
> 
> The reason I'm asking is that we (the IBM folks trying to bootstrap some
> XML tests) have about sixteen patches queued, but all are stuck with -1
> from Jenkins. From run to run, different tests will fail, often with
> timeout or other spurious sorts of messages, and are in most cases
> related to tests or infrastructure untouched by the patch series at
> all. I've been hesitant to squash my test case patches together just
> because I want to make sure that anything related to a specific test can
> easily be adjusted, moved, or otherwise quarantined.
> 
> We've been getting some review from Daryl, but would really like to
> start landing some of these (or making changes as required) to cut down
> the length of the patch queue. I presume that having a -1 next to all of
> them is what is standing in the way of getting more feedback and some
> +2s required to merge.
> 
> Advice?
> 
> Thanks!
> 
> -- 
> Dan Smith
> IBM Linux Technology Center
> 
> -- 
> Mailing list: https://launchpad.net/~openstack-qa-team
> Post to     : openstack-qa-team@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack-qa-team
> More help   : https://help.launchpad.net/ListHelp