Drop official support for CentOS build image

[PiotrSikora]

There is no official build for CentOS provided by LLVM folks, so we're stuck on old / community-maintained version of LLVM/clang (currently using 5.0, when 6.0 has been out for 4+ months and 7.0 is around the corner), which blocks update of the Ubuntu build image.

This is suboptimal considering the fact that Envoy is using bleeding-edge features of the C++ language.

Also, it seems that we don't use / verify the CentOS build image anywhere.

Thoughts?

cc @mattklein123 @lizan @htuch @ggreenway @jwfang

[ggreenway]

Can you elaborate on what is being blocked by using the old clang on centos? I've seen various comments/questions about centos in envoy forums and issues, so I presume some people are using this build, so I'm hesitant to pull the plug on it.

[PiotrSikora]

1. We're hardcoding version number in a few scripts (ci/build_setup.sh, tools/check_format.py),
2. clang-format-5.0 produces different output than clang-format-6.0.

Since we don't use CentOS build image anywhere on the official CI, those might be fine, but it's hard to tell if/when we break something, since it's unmaintained build image.

[htuch]

I wonder if we can adopt a policy for build images that, like with extensions, they need an owner/sponsor to keep alive.

[lizan]

Is it possible to keep CentOS image but drop LLVM/Clang from it? It still can be used for building release/test binaries with GCC.

[PiotrSikora]

@lizan Sure, but that doesn't solve anything - we have unmaintained CentOS build image that's not used anywhere, and we need to add workarounds for CentOS image regardless of whether the condition is no clang or no clang-6.0.

Since I'd like to move to clang-6.0 sooner rather than later (for no particular reason, but we used to run nightly snapshots and now we're a major release behind), how should we move forward with this?

I see 4 options (in order of my preference):

1. Drop official support for CentOS build image and update Ubuntu to clang-6.0.
2. Leave CentOS with clang-5.0, update Ubuntu to clang-6.0 and add workarounds so that build scripts work with both: clang-5.0 and clang-6.0.
3. Remove clang from CentOS, update Ubuntu to clang-6.0 and add errors for targets requiring clang.
4. Build clang-6.0 from sources on CentOS and update both images to clang-6.0.

I'm not sure how feasible is 4., seeing that we're building images on CircleCI and that there is no official maintainer of the CentOS build images.

[ggreenway]

I would lean towards option (2). We already use different versions of gcc between different platforms, so it doesn't seem like different versions of clang should be more of a problem.

[lizan]

different versions of clang would cause:

• clang-format output is slightly different between versions, we can make clang-6 canonical and enforce them in CI.
• sanitizers behaves differently on (likely) false positives/negatives, they need to be handled correctly in tests (e.g. tag no_asan, no_tsan).

I'm leaning towards (3) and leave CentOS build/test with GCC as best-effort.

[ggreenway]

I agree we need to define a specific version of clang-format that we format with, and possibly check_format won't work on CentOS.

For the actual build, I think I'm just arguing for not removing the existing tooling around CentOS. We don't run that build in CI anyways, so it's not officially supported in the same sense. I think various people/groups/companies already compile envoy for different linux flavors and versions, probably using whatever compiler is provided with their distro, so we already have issues with multiple compilers. Occasionally we get a PR that fixes the build for a different version of the compiler due to different warnings and whatnot, and I think that system (accepting PRs as they come, with the official project not devoting any effort to compiling with those compiler versions ourselves) is working fine.

So I'm advocating for leaving the CentOS stuff alone, and if a community member notices that something is broken, they can send a PR.