Passed [gamma.gamma_baseline_test](https://github.com/grpc/psm-interop/blob/main/tests/gamma/affinity_test.py) and [gamma.affinity_test](https://github.com/grpc/psm-interop/blob/main/tests/gamma/affinity_test.py) locally with those changes.
The docker image used for testing was pushed to Container Registry and can be tested locally using this flag:
`--client_image=gcr.io/grpc-testing/xds-interop/python-client:test_ssa_interop_python`
<!--
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#35596
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35596 from XuanWang-Amos:python_ssa_client_test af026547ef
PiperOrigin-RevId: 601164317
<!--
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#35633
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35633 from yijiem:labels-injector-patch 6876243943
PiperOrigin-RevId: 600931754
Example:
```
virtualenv Python module not installed. Attempting to install via pip.
error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.
If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.
If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.
See /usr/share/doc/python3.11/README.venv for more information.
note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
############################
Your administrator is _insisting_ on managing your packages themself. Try running `sudo apt-get install python3-virtualenv`
############################
```
Closes#35642
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35642 from gnossen:fix_fix_fix_protobuf 047470aaa2
PiperOrigin-RevId: 600909347
Instead, connect a real client, which gives us the ability to exercise the listener portion of the code too.
Closes#35625
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35625 from ctiller:shush-connect b8f78993c6
PiperOrigin-RevId: 600836565
This ensures that if a cluster is used both in the RouteConfig and via a ClusterSpecifierPlugin, and then the entry in the RouteConfig goes away, we won't unsubscribe and then resubscribe to the CDS resource.
Closes#35627
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35627 from markdroth:xds_rls_dynamic_subscription_fix c78afaf6ce
PiperOrigin-RevId: 600801766
`ProtoBitGen` provides a random number generator that returns values directly from fuzzer selected values, which allows us to test-into random selection algorithms deterministically.
Since the list of values provided by the fuzzer is limited, we need a fallback implementation. Previously we'd used something that was very correlated, and some of the distribution algorithms get into a very slow convergence mode when we do that (so we repeatedly return the same value for billions of iterations and cause timeouts in fuzzers).
Instead, when we run out of fuzzer supplied values, seed an mt19937 generator with the fuzzer selected values and use that from there on. Said generator will then produce values deterministically (for a given fuzzer input), but with a better distribution to allow convergence for fiddly algorithms.
Closes#35621
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35621 from ctiller:cg-timeout 6c9ef9cac5
PiperOrigin-RevId: 600607424
<!--
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.
-->
Follow-up to add privacy manifests to #35042
- [x] Update podspec template files
- [x] Align on manifest update:
```
git grep mach_absolute_time
src/core/lib/gpr/posix/time.cc:static uint64_t g_time_start = mach_absolute_time();
src/core/lib/gpr/posix/time.cc: ((double)(mach_absolute_time() - g_time_start)) * g_time_scale;
```
cc: @paulb777Closes#35542
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35542 from ncooke3:nc/privacy-manifests b0e0e57d2e
PiperOrigin-RevId: 600595032
Actually build O11y artifacts.
### Testing
* Manually installed the `.whl` and verified it's working locally (For Python 3.8 + Linux).
<!--
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#35578
PiperOrigin-RevId: 600566829
As announced in https://discourse.llvm.org/t/clang-16-notice-of-potentially-breaking-changes/65562, clang 16 defaults `-Wincompatible-function-pointer-types` to be on. This causes a number of hard errors due to implicit conversions between `void *` and `void`, such as:
```
../../../../src/ruby/ext/grpc/rb_channel.c:770:47: error: incompatible function pointer types passing 'VALUE (VALUE)' (aka 'unsigned long (unsigned long)') to parameter of type 'VALUE (*)(void *)' (aka 'unsigned long (*)(void *)') [-Wincompatible-function-pointer-types]
g_channel_polling_thread = rb_thread_create(run_poll_channels_loop, NULL);
^~~~~~~~~~~~~~~~~~~~~~
/root/.rbenv/versions/3.1.4/include/ruby-3.1.0/ruby/internal/intern/thread.h:190:32: note: passing argument to parameter 'f' here
VALUE rb_thread_create(VALUE (*f)(void *g), void *g);
^
../../../../src/ruby/ext/grpc/rb_channel.c:780:41: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
void grpc_rb_channel_polling_thread_stop() {
^
void
../../../../src/ruby/ext/grpc/rb_channel.c:786:30: error: incompatible function pointer types passing 'void (void *)' to parameter of type 'void *(*)(void *)' [-Wincompatible-function-pointer-types]
rb_thread_call_without_gvl(run_poll_channels_loop_unblocking_func, NULL, NULL,
```
This commit fixes these pointer types using wrapper functions where necessary.
This issue was also raised on the FreeBSD port of the grpc gem: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271540
<!--
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#34481
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/34481 from stanhu:sh-ruby-fix-clang-16 63c7424ad0
PiperOrigin-RevId: 600548467
Using `AF_UNSPEC` for both IPv4 and IPv6 queries does not work in all cases. Specifically, for `localhost:<>`, c-ares only returns the IPv6 record i.e. `::1`.
<!--
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#35530
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35530 from yijiem:enable-oss-ee-dns-posix 452b5a2d81
PiperOrigin-RevId: 599989537
<!--
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#35499
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35499 from dawidcha:cred_opts_copy_constr 330165930f
PiperOrigin-RevId: 599977221
Fixes#30385 for C++/cmake.
Add a `gRPC_DOWNLOAD_ARCHIVES` switch that is on by default but can be disabled for environments building without Internet connectivity.
Passes build tests:
```
$ python tools/run_tests/run_tests.py -l c++ --build_only
PASSED: tools/run_tests/helper_scripts/build_cxx.sh [time=7116.3sec, retries=0:0SUCCESS: All tests passed
=== run_tests.py DEBUG INFO ===
command: "tools/run_tests/run_tests.py -l c++ --build_only"
===============================
$
```
And tested in a Docker container with `eth0` down to ensure we can now build when `-DgRPC_DOWNLOAD_ARCHIVES="OFF"` is passed to cmake.
Closes#34587
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/34587 from matthewjmiller1:no-download-option 9c07bdce87
PiperOrigin-RevId: 599954208
In #35384 these two lines were forgotten and introduced a bug in the
script.
Sorry for the mistake.
Closes#35601
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35601 from lepistone:fixup-bigquery-project 100d4d68ad
PiperOrigin-RevId: 599951984
`GPR_BACKWARDS_COMPATIBILITY_MODE` was devised to support old Linux kernel with old glibc but gRPC is now expected to support glibc 2.17 and later (2.17 is derived from the oldest but supported Linux distro, CentOS 7). Effectively, gRPC doesn't need `GPR_BACKWARDS_COMPATIBILITY_MODE` anymore. Hence, let's remove it.
gRPC Python and Ruby that distribute binary artifacts already began to use `manylinux` environment dealing with this issue in a better way so they don't need this flag anymore.
Closes#35602
PiperOrigin-RevId: 599895270
Regardless of whether we change server behavior to continue running after a failed `getpeername` on accept, this improves the logs for the current server behavior.
Related to #35076Closes#35611
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35611 from drfloob:louder-server-stoppage-on-bad-getpeername 2d1e69aff0
PiperOrigin-RevId: 599886474
This PR is required in order to upgrade to the `master` branch version of protobuf. To do this, we upgrade to the latest version of `rules_python` by:
- Adding in explicit dependencies on all PyPi Bazel test dependencies
- Resolving the circular dependency this creates for `xds-protos` by giving it a Bazel build
- Generating the Python code for `xds-protos` as part of `generate-projects.sh` since doing so directly in Bazel would be highly fragily, dependent on many other projects' Bazel builds
Closes#34945
PiperOrigin-RevId: 599875020
Add `gamma.csm_observability_test` test suite to `grpc/core/master/linux/psm-csm` Kokoro job.
Closes#35588
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35588 from sergiitk:psm-kokoro-csm_observability_test dc0c0f234d
PiperOrigin-RevId: 599664886
A few improvements to the promise context system (more coming)
Allow subclassed contexts:
If we have multiple different kinds of a base context, allow `GetContext<Derived>()` to mean `down_cast<Derived*>(GetContext<Base>())` everywhere for brevity.
Allow custom context lookup:
For a base context type, allow customization of how that context is looked up.
These two together allow:
1. normalization of activity lookup and context lookup to the same syntax (so we can write `GetContext<Activity>()` everywhere now
2. Party & Activity to share a context, so that anywhere we need to do a party specific operation we can write `GetContext<Party>()->...` and safely know that it's the current activity *and* it's a party.
Closes#35592
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35592 from ctiller:contextual-types 37ef948a36
PiperOrigin-RevId: 599651708
We've got a few situations coming up with promises that will want a "broadcast new value to everywhere" situation.
Closes#35552
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35552 from ctiller:obs 30fd697ae3
PiperOrigin-RevId: 599609399
Fix: https://github.com/grpc/grpc/issues/35555
<!--
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.
-->
Only call constructors when absolutely necessary (empty trivially constructible types don't need construction!!)
Similarly for destructors, if the destructor is trivial it means C++ will do no work destructing it... let's not even do the virtual function call to get there.
(also fix a bug where we weren't calling this stuff anyway, and add a test that would have caught that)
Closes#35591
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35591 from ctiller:filter-min 2933152d61
PiperOrigin-RevId: 599521371
Vignesh Babu
AJ Heller
Craig Tiller
apolcyn
Xuan Wang
Yash Tibrewal
Yijie Ma
Eugene Ostroukhov
Richard Belleville
Esun Kim
Mark D. Roth
Nick Cooke
Stan Hu
Alisha Nanda
David Chamberlin
Matt Miller
Leonardo Pistone
Sergii Tkachenko