On 5/21/21 1:35 PM, Neha Ojha wrote:
On Thu, May 20, 2021 at 8:49 PM Kefu Chai <kchai@xxxxxxxxxx> wrote:
hi folks,
tl;dr: can we stop building/testing master on bionic for a better GCC?
long story: two months ago, we migrated[0] our CI jobs running "make
check" from ubuntu/bionic to ubuntu/focal so we have access to more
packages offered by focal for testing.
but we are still suffering[1] from the ancient packages offered by bionic:
- buggy tcmalloc. see https://github.com/ceph/ceph/pull/41340
- GCC 7.5.0 shipped along with ubuntu/bionic. i think the support of
std::filesystem is just the tip of the iceberg, as we've migrated to
C++17, there will be more and more demand for a compiler and a
standard library with better C++17 (and C++20 in future) support.
GCC-7 has good support[2] of C++17, but that does not imply that
libstdc++ shipped along with GCC-7 has.
but we have to build and test on bionic[3], for couple reasons:
- some upgrade tests from octopus are performed on bionic. for
instance, see https://github.com/ceph/ceph/tree/master/qa/suites/upgrade/pacific-x/parallel
- cosbench used by perf tests needs bionic: see
https://tracker.ceph.com/issues/49139
- // please note rados/thrash-old-clients/distro$/ubuntu_18.04.yaml is
safe even after we stop building master on bionic, as we've
switched[4] to cephadm for thrash-old-clients
and because of https://tracker.ceph.com/issues/50218, we cannot use
ubuntu-toolchain-r PPA repo for newer GCC.
so, i propose we
- drop building/testing master on bionic.
- drop the upgrade test from pacific on bionic
I think we need to tread carefully here. Losing upgrade test coverage
is not ideal.
We've still got focal for ubuntu coverage. If we're dropping it for
quincy, a user would need to upgrade past bionic to run the next version
anyway.
- drop the cosbench workload from rados/perf test suites
I have confirmed again that https://tracker.ceph.com/issues/49139
continues to be a problem with focal so I've proposed
https://github.com/ceph/ceph/pull/41486.
I'd be curious to know what's the most commonly used rgw workload
people use for benchmarking purposes. Perhaps, we should think about
integrating it with the perf suite.
Agreed, maybe it's time to focus on other tools.
Josh
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx