impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Behm <alex.b...@cloudera.com>
Subject Re: test_ddl_stress likely not getting regular, automated runs
Date Fri, 10 Feb 2017 00:58:17 GMT
I think we expected this test to run regularly, at least in exhaustive mode.

Looks like I was unaware of this workload core/exhaustive mess and disabled
that test in this commit: 992c261d

Certainly was not on purpose.

On Wed, Feb 8, 2017 at 3:45 PM, Tim Armstrong <tarmstrong@cloudera.com>
wrote:

> For what it's worth there's a similar problem with TestSpillStress that I
> came across too. I was surprised when I realised too.
>
> On Wed, Feb 8, 2017 at 3:38 PM, Michael Brown <mikeb@cloudera.com> wrote:
>
> > Hello,
> >
> > Background: I am conducting an audit of metadata tests.
> >
> > A particular manifestation of IMPALA-3947 [0] is that the test module
> > test_ddl_stress.py isn't runnable via any buildall.sh option. I expect
> > this means test_ddl_stress.py isn't being run regularly except by
> > conscientious developers running it locally. Note that this test was
> > not disabled as part of the commit "IMPALA-2605: Omit the sort and
> > mini stress tests".
> >
> > I'm interested to know any history around this.
> >
> > Could any community members who have been around for several years,
> > especially those who work on the Catalog, shed light on this? Were you
> > assuming test_ddl_stress.py was being run regularly? Or do you know to
> > run it by hand? Do you know it to be reliable and useful, and it
> > should be included in regular runs, or do you know it to be flaky and
> > needing work?
> >
> > It's fine if no one knows any such answers, but they would lend
> > context to getting test_ddl_stress running regularly.
> >
> > Thanks.
> >
> > [0] https://issues.cloudera.org/browse/IMPALA-3947
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message