[Gpr_To_Absl_Logging] Reducing log spam because of complaints from user
Closes#37106
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37106 from tanvi-jagtap:reduce_verbosity 044c5aade1
PiperOrigin-RevId: 647905894
[Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#37069
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37069 from tanvi-jagtap:src_core_lib_security a95b1b9543
PiperOrigin-RevId: 647857734
[Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#37041
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37041 from tanvi-jagtap:src_core_ext_transport_binder aae32adf3c
PiperOrigin-RevId: 647853742
This allows CallTracers to be created with parameters dictated by
channel args.
For the moment, I've used the EventEngine `EndpointConfig` API to expose
the channel args here, so as to avoid directly exposing
`grpc_core::ChannelArgs`. We should determine a better API here before
we de-experimentalize the stats APIs.
Also add an experiment to be used in a subsequent PR.
PiperOrigin-RevId: 647730284
[Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#37068
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37068 from tanvi-jagtap:src_core_ext_transport_binder_reduced 4f449b6563
PiperOrigin-RevId: 647559361
[Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#37067
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37067 from tanvi-jagtap:src_core_lib_event 4ddf52b071
PiperOrigin-RevId: 647556953
Flaky tests are fixed now.
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#37061
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37061 from yousukseung:work-serializer-retry 610a8e0e1a
PiperOrigin-RevId: 647366412
Reports to the metrics reporter may happen asynchronously with work serializer dispatch.
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#37005
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37005 from yousukseung:xds-client-tests-fix d65d00a410
PiperOrigin-RevId: 647066953
Move event engine context to be an arena based context, and have party host arena directly.
Now `Party` can directly inject all context necessary without needing to call out to the derived type; this makes `Party` instantiable by itself (no need to inherit from it - though we'll still want to for `CallSpine` to simplify some arena lifetime management), meaning we can start to consider eliminating the base class `Activity` and merging these types.
Closes#37015
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37015 from ctiller:chaotic-party 7f44b37b5d
PiperOrigin-RevId: 646963003
[Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#37030
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37030 from tanvi-jagtap:src_core_tsi be0b6ee33c
PiperOrigin-RevId: 646719152
[Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#37045
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37045 from tanvi-jagtap:src_core_lib_iomgr 2e01be5721
PiperOrigin-RevId: 646700524
There were two problems here:
1. A pre-existing bug in the chaotic good connector whereby it was using `std::shared_ptr<>` instead of `RefCountedPtr<>` for `HandshakeManager`, thus failing to account for the internal refs taken inside `HandshakeManager` before deciding to delete the object.
2. A change made as part of #37018 made `HandshakeManager` less tolerant to a caller that unrefs the `HandshakeManager` in the `on_handshake_done` callback, which may be run in another thread while the first thread is still holding the mutex in `HandshakeManager::DoHandshake()`. To be defensive for this case, `DoHandshake()` now holds its own ref, which it releases after releasing the mutex.
The second problem is in principle not specific to chaotic good, but in practice it almost certainly is, because the chttp2 connector does a bunch of other work (e.g., starting another timer for the settings timeout) before unreffing the `HandshakeManager`, so it would not trigger this race condition.
Closes#37049
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37049 from markdroth:chaotic_good_connector_thready_tsan_fix 6821dd1418
PiperOrigin-RevId: 646628702
This moves some low-hanging fruit out of the `grpc_xds_client` BUILD target:
- `xds_certificate_provider`
- `xds_certificate_provider_store`
- `xds_credentials`
- `xds_file_watcher_certificate_provider_factory`
Subsequent PRs will do more refactoring.
Closes#37032
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37032 from markdroth:xds_build_target_refactoring eac85eb7bc
PiperOrigin-RevId: 646627448
Allow `CallFilters` to have more than one `CallFilters::Stack` attached to it, and execute all of the stacks when executing.
This permits a trivial implementation of `PassThrough` for `Interceptor`, and allows elimination of an inserted `ForwardCall` if an interception chain terminates in a `CallDestination` preceded by one or more filters.
Built on #36984 which should be merged first.
Closes#36985
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36985 from ctiller:step-by-step 07b14c9d91
PiperOrigin-RevId: 646586483
This test very occasionally needs to have gRPC initialized, so adding the init/shutdown scope just where it's needed.
Closes#37050
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37050 from ctiller:ci 4baad7af76
PiperOrigin-RevId: 646586430
When using gRPC client alongside kopf (Python framework for writing K8s operators), the existing code fails because of 9243c8fbb2/kopf/_cogs/aiokits/aiotoggles.py (L40). This is because the existing `if candidate:` condition invokes the `__bool__` magic method of the `Toggle` class from kopf.
Closes#36837
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36837 from mboutet:patch-1 831152ca47
PiperOrigin-RevId: 646539016
[Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#37039
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/37039 from tanvi-jagtap:large_file_01 d7705c0bf6
PiperOrigin-RevId: 646417700
[grpc][Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#36942
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36942 from tanvi-jagtap:src_core_lb 524b45fef1
PiperOrigin-RevId: 646311061
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#37034
PiperOrigin-RevId: 646276954
Originally when I was implementing call-v3 I added async handling for server trailing metadata because it was symmetrical with all the other handling we had. Turns out that we really don't need this, and further it's probably harmful to our ability to reason about the stack - so I'm removing that capability.
Closes#36984
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36984 from ctiller:no-infallible-seq f3b3548685
PiperOrigin-RevId: 646146666
Updates to channel init registration ordering:
* Add ability to float filters towards the top of the stack or to sink them towards the bottom. This is a secondary hint to the explicit ordering constraints that we have. To avoid possible ambiguities we enforce that there can never be two tops/two bottoms available to add simultaneously (if this eventuality appears we simply require an explicit ordering between the two filters).
* Add the ability to skip some filters in the V2 stack (so we can start building V3 only filters)
Along the way:
* Add hashability to `UniqueTypeName`
* Remove `UniqueTypeName` copy constructor (this is just the default copy constructor anyway, and its presence started to confuse `clang-tidy`).
* Separate the dependency tracking and logging parts of channel_init.cc. This was necessary for my brain to be able to process how to implement the new ordering constraints. Happily, it also eliminates an O(n**2) loop in initialization!
Closes#36993
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36993 from ctiller:ordering-innit e9d08e7a81
PiperOrigin-RevId: 646144240
Tanvi Jagtap
Esun Kim
Craig Tiller
Mark D. Roth
Tanvi Jagtap
Nana Pang
Yash Tibrewal
Yousuk Seung
AJ Heller
Larry Safran
Easwar Swaminathan
Maxence Boutet
Yijie Ma