go.mod: bump gRPC and google SDKs

[rhu713]

The first commit bumps gRPC to v1.49.0 as it is needed by google storage v1.27.0.

The second commit bumps cloud.google.com/go/storage to 1.27.0. This version contains the fix for the first request GCS chunked uploads not being retried. Bump pubsub version to maintain compatibility with transitive dependencies.

Release note: None

[cockroach-teamcity]

All committers have signed the CLA.

[cockroach-teamcity]

This change is 

[knz]

1. How did you run this upgrade?

   If you used go get -u you've taken on too many upgrades.

   The proper way would be e.g. go get cloud.google.com/go/[email protected]

   (If you've seen -u mentioned in instructions, please tell us. We might need to update the instructions. That -u is generally undesirable - see build/README: tell folk to avoid -u #90984)

2. If the updates to grpc and protobuf are absolutely required, then let's pull those off in a separate PR that would run first. We want to see a clear CI + run a more careful examination of changes there, separately from your change.

[dt]

@knz: Google cloud storage 1.27 explicitly depends on grpc v1.49.0, but there is a breaking api change in that they unbroke in 1.50, which is why we're going to that instead of 1.49. different library, nvm

All the changed deps here are either first-party golang libraries or google's. The only one that really catches my attention is grpc, but as mentioned above, that one is forced, so not much to do there other than try it and let the roachtests see what they think.

[knz]

not much to do there other than try it and let the roachtests see what they think.

See my previous message:

let's pull those off in a separate PR that would run first. We want to see a clear CI + run a more careful examination of changes there, separately from your change.

[knz]

Given the amount of infra dep changes here, we certainly need to look at this more carefully. It's a shame that the github review interface makes this difficult.

[dt]

What would be the benefit of splitting this into separate PRs? It is already only a dep bump, not feature code changes.

If we land it as is an roachtests suggest there is an issue, then we revert it but know which test to use when bisecting library-by-library/version-by-version. Doing a piecemeal bump when we don't even know if or what we'd be worried about doesn't seem required (nor is it what we've done in the past)

[knz]

What i'd like us to achieve is a standard by which grpc/protobuf/etc upgrades "stick out" in some fashion, and get extra attention by virtue of sticking out on their own.

Currently we are unable to get that extra attention because they get bundled with other things that seem innocuous, like this PR.

How do you suggest getting that extra attention, short of a separate PR with a distinctive title? (Like "upgrade gRPC to version X, protobuf to version Y")?

[dt]

How about:
a) do it in two commits (since log is what most people will look at after the fact) so gRPC gets its own
b) retitle the PR to "go.mod: bump gRPC and google sdk" or similar to stick out more?

[knz]

yes that would be an improvement

[rhu713]

hey @knz / @dt. I separated the gRPC v1.49.0 bump into its own commit and updated the PR title and commit descriptions. PTAL when you get a chance. Thanks!

[knz]

I've looked at the gRPC bump and checked for the following:

• no licensing changes
• no major configurability changes (crdb tweaks quite a few options - none of them are affected here)

However there's quite a few changes related to dial and retries. i've asked a double check from the KV team here: https://cockroachlabs.slack.com/archives/C0KB9Q03D/p1667737349258559

[knz]

Quoth @erikgrinaker :

Pavel tried this a while ago, but had to roll back [...] Got a bunch of test failures and such.

See:

• *: upgrade grpc to v1.47.0 #88470 - upgrade to 1.47, which had outright bugs
• upgrade grpc to v.1.49.0 #88562 - upgrade to 1.49
• *: downgrade grpc to v1.46.0 #88745 - revert to 1.46

Note that the test failures (in roachtest nightlies) could not be certainly pinned on the gRPC upgrade. So there is more to investigate.

However, at the very least this means we would benefit from manually running the nightly CI run on this dep bump PR, so as to collect the test results without impacting the master branch.

[knz]

manually running the nightly CI run on this dep bump PR

in case you don't know this yet - you can manually trigger a TC target on any branch using the web UI.

[erikgrinaker]

I'm pretty sure the kv/splits/nodes=3/quiesce=* failures were down to gRPC. I'd try to upgrade to 1.49 (previous versions have known bugs), and see if we can get that test to pass reliably. Might just need some tweaks in our integration, we didn't look closer (this was blocking 22.2).

[erikgrinaker]

Is anyone actively working on the gRPC upgrade? If not, I can pick it up "soon".

[erikgrinaker]

Bumping gRPC to v1.51.0 over in #93867, no longer see the roachtest failure we had with v1.49.0.

[knz]

@rhu713 I think this was achieved by other means, right? do we need to keep this PR open?

[dt]

bumped elsewhere