Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #14898 > unrolled thread

Bug#1030096: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ?

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1030096: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2023-02-06 09:10 +0100
    Bug#1030096: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ? Diane Trout <diane@ghic.org> - 2023-02-06 20:40 +0100
      Bug#1030096: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ? "Rebecca N. Palmer" <rebecca_palmer@zoho.com> - 2023-02-06 22:50 +0100

#14898 — Bug#1030096: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ?

(Background: the pandas + dask transition broke dask.distributed and it 
was hence removed from testing; I didn't notice at the time that if we 
don't get it back in we lose Spyder.)

On 05/02/2023 21:44, Rebecca N. Palmer wrote:
> I currently have this in a state where it sometimes succeeds and 
> sometimes doesn't:
> https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/tree/fix1030096
> 
> Tests I've seen to fail multiple times (and don't have a fix for):
> test_balance_expensive_tasks[enough work to steal]
> https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/jobs/3902376
> (Seems to be the most common problem.  Using @pytest.mark.flaky to try 3 
> times doesn't seem to have helped, suggesting that if it fails once it 
> keeps failing in that run.  Applying part of upstream pull 7253 seemed 
> to make things worse, but I haven't tried applying the whole thing.)
> test_popen_timeout
> https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/jobs/3902745
> 
> Tests I've seen to fail once:
> test_stress_scatter_death
> https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/jobs/3902040
> test_tcp_many_listeners[asyncio]
> https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/jobs/3896327

And now test_failing_task_increments_suspicious (once):
https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/jobs/3903956
(We don't have to pass build-i386 (as this is an arch:all package) or 
reprotest, but if these are effectively-random failures, they might also 
be able to occur in build or autopkgtest.)

I'm probably the wrong person to be working on this - I don't know 
enough about this package to say whether ignoring this kind of 
intermittent failure (as my 'flaky' marks do) is appropriate, or to have 
much idea how to actually fix it.

We could also try upgrading dask + dask.distributed to 2023.1, but 
that's a risky move at this point.

[toc] | [next] | [standalone]

#14903

On Mon, 2023-02-06 at 11:13 +0100, Andreas Tille wrote:
> Hi Rebecca,
> 
> Am Mon, Feb 06, 2023 at 07:59:17AM +0000 schrieb Rebecca N. Palmer:
> > (Background: the pandas + dask transition broke dask.distributed
> > and it was
> > hence removed from testing; I didn't notice at the time that if we
> > don't get
> > it back in we lose Spyder.)
> 
> as far as I know Diane has put quite some effort into dask and I
> understood that dask and dask.distributed are closely interconnected.
>  

Hi now.

My fragments of time were spent fighting with numba, and I didn't have
the energy to be thinking about dask.distributed.

Numba should be in a better place right now. So I can set my build
machine to trying to build it and seeing where we are with it right
now.

The most important thing about dask / dask.distributed is they really
should be at about the same upstream version. I'm not 100% sure how to
mark that in the d/control file. Also upstream might have some ability
to do minor releases independently.

But if we do a new upstream release of dask, it needs to be paired with
a new upstream release of dask.distributed. And in my experience
dask.distributed is the one that's harder to get to work right.

Diane

[toc] | [prev] | [next] | [standalone]

#14905

I agree that xfailing the tests *may* be a reasonable solution.  I'm 
only saying that it should be done by someone with more idea than me of 
whether these particular tests are important, because blindly xfailing 
everything that fails is effectively not having tests.

If we do choose that approach, at least test_balance_expensive_tasks 
needs to be an outright xfail/skip not just a flaky, because when it 
fails it fails repeatedly.

On 06/02/2023 19:38, Diane Trout wrote:
> The most important thing about dask / dask.distributed is they really
> should be at about the same upstream version.

I knew that, and was planning on 2022.12.1 of both when I decided to go 
ahead with pandas.  What went wrong was that I only tested a build, not 
an autopkgtest, and thought the failing tests were dask.distributed's 
(known) inability to run all its tests in a buildd environment.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027254#21

> I'm not 100% sure how to
> mark that in the d/control file.

Possibly
Depends: python3-dask (>= 2022.12.1~), python3-dask (<< 2022.12.2~)
but I haven't tested that.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web