Try upgrading third_party/protobuf version to 3.14.0-rc2

[acozzette]

This pull request probably shouldn't be merged, but by running the tests we can find out if there will be any issues with protobuf 3.14.0.

@veblush

[acozzette]

@veblush Do you know if this PR needs the "kokoro: run" tag for the tests to run?

[acozzette]

@veblush Would you mind adding the Kokoro tag one more time? I had to tweak the Ruby version and I'm hoping this will fix some of the failures that came up.

[dlj-NaN]

The Python failures seem to be due to google.auth's use of pkg_resources. Basically, using pkg_resources makes namespace-package'd imports order-dependent under certain installation strategies.

google.auth definitely does use package_resources, but Pip installs packages in a way that elides this in namespace packages, avoiding the order-dependence pathology. So the failure also also depends on exactly how packages are installed.

It might help to update rules_python to 0.1.0 first:

• https://github.com/grpc/grpc/blob/master/bazel/grpc_python_deps.bzl#L37-L41
• should use: https://github.com/bazelbuild/rules_python/releases/tag/0.1.0

That fixed several bugs around Pip usage, which might also resolve this.

[acozzette]

@dlj-NaN Thanks for looking into this, David. I don't think I will have time to fully resolve the issue before releasing protobuf 3.14.0, but at least it appears that it is probably not a protobuf issue.

[jtattermusch]

Superseded by #24855

[jtattermusch]

@dlj-NaN Thanks for looking into this, David. I don't think I will have time to fully resolve the issue before releasing protobuf 3.14.0, but at least it appears that it is probably not a protobuf issue.

Turns out the issue actually was caused by a protobuf PR - protocolbuffers/protobuf#7902. After some investigations @gnossen has discovered that Envoy also ran into the same problem and we've implemented the same workaround as envoy did. Besides that, we needed 2 backports into 3.14.x to fix a windows build problem for python.

So to summarize there were 3 different issues with the 3.14.0 release that were preventing gRPC from upgrading and they were exhibiting in the test results since this PR was created 2 months ago. Despite that, the 3.14.0 protobuf release was published as if everything was ok - not an ideal outcome. I've now finally managed to upgrade gRPC to protobuf 3.14.0 almost two months later: #25131 but it wasn't easy. Next time protobuf does a pre-release, we need to be more attentive to the test failures and make sure they get resolved before the stable release, otherwise we are making this process longer and more painful for everyone involved.