Another week has passed, and the original issues seem to have been resolved by retrying. Thanks for everyone involved in that.
In the mean time, a new test regression occurred at https://autopkgtest.ubuntu.com/packages/victoriametrics/hirsute/amd64, log can be seen at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/v/victoriametrics/20210107_084114_85c06@/log.gz
2021-01-07T08:40:46.015Z info VictoriaMetrics/lib/mergeset/table.go:203 table "/tmp/autopkgtest.a1SU4e/autopkgtest_tmp/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/TestStorageRegisterMetricNamesConcurrent/indexdb/1657E67DA0CA2C97" has been opened in 0.002 seconds; partsCount: 0; blocksCount: 0, itemsCount: 0; sizeBytes: 0 storage_test.go:699: unexpected error: error in SearchMetricNames: cannot search for tsids, since more than 2 concurrent searches are performed during -1610008847.000 secs; add more CPUs or reduce query load --- FAIL: TestStorageRegisterMetricNamesConcurrent (0.49s)
I suppose the testsuite is running on a machine with only 2 CPUs and expects more ressources? I've retriggered the test but I'm concerned this excercise might be a waste of resources. Does anyone share this concern and/or has any thoughts on how to avoid this?
Best,
-rt
Best,
-rt
On Thu, Jan 7, 2021 at 11:31 AM Reinhard Tartler <siretart@gmail.com> wrote:
Cool, thanks.IT seems we have an additional failure now at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/v/victoriametrics/20210107_084114_85c06@/log.gz -- the relevant part might be this one:2021-01-07T08:40:46.015Z info VictoriaMetrics/lib/mergeset/table.go:203 table "/tmp/autopkgtest.a1SU4e/autopkgtest_tmp/_build/src/github.com/VictoriaMetrics/VictoriaMetrics/lib/storage/TestStorageRegisterMetricNamesConcurrent/indexdb/1657E67DA0CA2C97" has been opened in 0.002 seconds; partsCount: 0; blocksCount: 0, itemsCount: 0; sizeBytes: 0 storage_test.go:699: unexpected error: error in SearchMetricNames: cannot search for tsids, since more than 2 concurrent searches are performed during -1610008847.000 secs; add more CPUs or reduce query load --- FAIL: TestStorageRegisterMetricNamesConcurrent (0.49s)Maybe the test machine doesn't have enough CPUs for these tests? Can we retry the failing tests on larger machines?
-rtOn Thu, Jan 7, 2021 at 3:32 AM Lukasz Zemczak <lukasz.zemczak@canonical.com> wrote:Hey Reinhard,
I see that at least golang-github-canonical-go-dqlite seems like a
good candidate to hint with a force-reset-test - I'll do that later
today (as it only passed *once* in its whole testing history, so it's
not a reliable testsuite).
I have retried one of the failures there and will try seeing if the
other failures make any sense.
Cheers,
On Sun, 3 Jan 2021 at 22:11, Reinhard Tartler <siretart@gmail.com> wrote:
>
> Hi folks,
>
> I couple of golang packages I care deeply about are stuck in hirsute-proposed due to autopkgtest failures that I had a hard time understanding. I've come to the conclusion that the problem must be related to https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#golang-golang-x-sys
>
> It seems that there are regressions in the following packages:
>
> - golang-github-canonical-go-dqlite
> - golang-github-lucas-clemente-quic-go
> - golang-google-grpc
>
> I'm not familiar with those testsuites, but on the first look, there might be timing issues.
>
> I'd appreciate some thoughts/comments on helping golang-golang-x-sys migrate to hirsute.
>
> Thanks!
>
> --
> regards,
> Reinhard
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--
Łukasz 'sil2100' Zemczak
Foundations Team
lukasz.zemczak@canonical.com
www.canonical.com
--regards,
Reinhard
regards,
Reinhard
Reinhard
