On 09/14/2012 06:51 AM, Jaroslav Henner wrote:
> I think unittests may be relatively easily split between several Jenkins
> jobs just by specifying which packages to run. Following might be
> executed in different Jobs:
>
> nose -w PATH_TO_TEMPEST tempest.tests.compute
> nose -w PATH_TO_TEMPES
On 13.9.2012 18:21, Jay Pipes wrote:
On 09/13/2012 06:43 AM, Sean Dague wrote:
On 09/13/2012 12:42 AM, Vishvananda Ishaya wrote:
Brian Waldon and I discussed this today. We came up with an idea which is to have the
tempest run on stable/ during the dev cycle, and after the last
milestone turn
On 09/13/2012 06:43 AM, Sean Dague wrote:
> On 09/13/2012 12:42 AM, Vishvananda Ishaya wrote:
>> Brian Waldon and I discussed this today. We came up with an idea which is to
>> have the tempest run on stable/ during the dev cycle, and
>> after the last milestone turn it on during the bugfixing ph
On 09/13/2012 12:42 AM, Vishvananda Ishaya wrote:
Brian Waldon and I discussed this today. We came up with an idea which is to have the
tempest run on stable/ during the dev cycle, and after the last
milestone turn it on during the bugfixing phase. The potential disadvantage of this
approach i
Brian Waldon and I discussed this today. We came up with an idea which is to
have the tempest run on stable/ during the dev cycle, and after
the last milestone turn it on during the bugfixing phase. The potential
disadvantage of this approach is that it could potentially make bugfixes a
little
Jay Pipes writes:
> On 09/07/2012 08:13 PM, Dan Smith wrote:
>>
>> Running tempest tests in parallel is definitely a good goal to
>> have. However, I believe that all the tests run in a gate are done
>> sequentially right now, correct? Seems like if we kicked off tempest at
>> the same time as t
On 09/07/2012 08:13 PM, Dan Smith wrote:
> DW> We also have a different problem with running tests in parallel
> DW> now. None of the newly designed basic/advanced ops test can be run
> DW> in parallel given their dependency between tests. The only way I can
> DW> think of to proceed would be to re
DW> We also have a different problem with running tests in parallel
DW> now. None of the newly designed basic/advanced ops test can be run
DW> in parallel given their dependency between tests. The only way I can
DW> think of to proceed would be to rework the nose plugin to run test
DW> classes in p
We also have a different problem with running tests in parallel now. None of
the newly designed basic/advanced ops test can be run in parallel given their
dependency between tests. The only way I can think of to proceed would be to
rework the nose plugin to run test classes in parallel, but test
Jim, we discussed this at the QA meeting and would appreciate your going
ahead with this.
We are going to raise the current problems at the nova meeting today and
see if we can get more attention to the
breakages whose tests in tempest have been commented out. We hope that
(3), because it dire
On 09/05/2012 09:03 PM, James E. Blair wrote:
> Here's what I'd like to propose instead:
>
> 1) Make the tempest gate symmetrical -- cross-project gating works best
> when all the projects gate on the same tests so that one project can't
> break another.
Hmm. Well, this really is just circumventi
DK> This situation is pretty bad.
Agreed. I wonder if it makes sense to enable full-run tempest gating
temporarily as we close in on the final days of Folsom? It might not
make sense during open development, but at this point, it would surely
make sense to me to require people's (say, nova) patche
A bunch of tests are failing now. I can reproduce some of them locally
and filed https://bugs.launchpad.net/nova/+bug/1046870.
https://bugs.launchpad.net/tempest/+bug/1039739 may also be related to this.
This situation is pretty bad.
-David
On 9/5/2012 9:03 PM, James E. Blair wrote:
Hi,
In
Thanks, Jim. That sounds like a good start. One thing that concerned me
was that some of the tests in tempest that I had to skip to get tempest
working were flakey. There are still some existing flakeys. It is not
clear what part of this is due to jenkins infrastructure vs nova
regressions or o
Hi,
In last weeks QA meeting, there was some talk about making improvements
around devstack-gate and tempest.
As I understand it, one of the problems is that things are changing in
other projects that are causing tests in the full (non-smoke) tempest
suite to fail, which prevents changes being me
JB> We're almost done with a project to move the build artifacts to a
JB> static web server, where we plan to keep them indefinitely. The
JB> artifacts in jenkins do have an expiration (currently about a
JB> month), and we actually want to drastically shorten that because
JB> long build histories
JP> This would be ideal! Unfortunately, I don't know of a way to do this
JP> with nosetests/unittest(2) in Python. Very open to suggestions,
JP> though :)
Ah, okay, hmm.
JP> Right now? Venice, Italy. In the last few days, Milan, Istanbul,
JP> Sofia. Next couple days, Florence then Rome, then hom
On 08/21/2012 05:45 PM, Dan Smith wrote:
> In other suites, I've seen an XFAIL result used to mark tests that we
> know are failing right now so that they're not SKIPped like tests that
> are missing some component, but rather just not fatal to the task at
> hand. Maybe something like that would be
David Kranz writes:
> Thanks, Jim. It seems that the tests are passing after the submission
> to skip some tests. That still leaves the problem of figuring out what
> the problems are. I want to file a bug about the fact that there are
> backtraces in the n-cpu log even on a "successful" build. I
JB> Oh, I thought you were talking about gating;
Well, I'm (incorrectly) using them interchangeably. I guess I better
stop that before someone gets hurt! :)
JB> the check pipeline tests patches independently, exactly as they are
JB> uploaded. So if you upload three dependent patches, it will run
Dan Smith writes:
> I just verified this by looking at the zuul queue link you provided. I
> see in the check queue things in the following order:
>
> 11411, 11500, 11823, 11754, 11440, 11351, 11353, 11482
Oh, I thought you were talking about gating; the check pipeline tests
patches independentl
JB> * Dependent patch series are tested in the correct order (regardless of
JB> the order in which individual patches are approved, and patches are
JB> only queued for testing once all the patches ahead of them are
JB> approved). This eliminated a huge amount of churn, as you can
JB> imagi
Thanks, Jim. It seems that the tests are passing after the submission to
skip some tests. That still leaves the problem of figuring out what the
problems are. I want to file a bug about the fact that there are
backtraces in the n-cpu log even on a "successful" build. I would
include a link to t
Dan Smith writes:
> One thing I noticed while doing some of this was that Jenkins doesn't
> seem to know about dependent patches, and will often run them in some
> sub-optimal order. This means that if the third patch in a series of ten
> is broken, it still runs everything ten times, instead of
JB> 1) We designed the devstack-gate with a facility to install the SSH
JB> key of the developer whose change failed onto the VM and give it to
JB> them for debugging purposes -- however, we've yet to have a
JB> devstack-gate node provider give us permission to hand out VMs like
JB> that. I'm sorr
David Kranz writes:
> I just submitted https://review.openstack.org/#/c/11755/ to skip the
> tests that are failing. I filed three bug tickets too. I can only
> reproduce one of them in my environment (the one where the error code
> seems to have changed). BTW, I looked at the nova logs for a tem
I just submitted https://review.openstack.org/#/c/11755/ to skip the
tests that are failing. I filed three bug tickets too. I can only
reproduce one of them in my environment (the one where the error code
seems to have changed). BTW, I looked at the nova logs for a tempest
build that succeeded
DW> I've been reviewing the test failures from the gating job and what
DW> concerns me is that at least some of them are legitimate.
Yeah, indeed, I didn't mean to minimize the severity of the actual
issues, I just wonder if gating new tempest changes on whether or not
the suite runs "right now"
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 d
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
temp
30 matches
Mail list logo
