Changes include:
- Implementing missing attributes. e.g. 'gen_ai.agent.name'
- Specifying reasons for not filling out some conditionally required attributes. e.g. 'gen_ai.data_source.id'
- Specifying reasons for not including certain attributes which are specified in current semconv. e.g. inference attributes on agent spans
PiperOrigin-RevId: 811379706
Cloud Trace, Cloud Monitoring and Cloud Logging integrations are set up via OTel if otel_to_cloud CLI param/fast_api arg is provided.
This is similar to current Cloud Trace integration via trace_to_cloud, just extended to Monitoring and Logging as well.
PiperOrigin-RevId: 807385680
Cloud Trace, Cloud Monitoring and Cloud Logging integrations are set up via OTel if otel_to_cloud CLI param/fast_api arg is provided.
This is similar to current Cloud Trace integration via trace_to_cloud, just extended to Monitoring and Logging as well.
PiperOrigin-RevId: 807285744
Cloud Trace, Cloud Monitoring and Cloud Logging integrations are set up via OTel if otel_to_cloud CLI param/fast_api arg is provided.
This is similar to current Cloud Trace integration via trace_to_cloud, just extended to Monitoring and Logging as well.
PiperOrigin-RevId: 807230668
Use the A2A Python SDK for client support for A2A Remote clients. This enables A2A based agents that use gRPC or RESTful interfaces, as well as the jsonrpc support. This also simplifies creation of clients and provides simpler mechanisms to inject credentials and observability into the remote agent interactions.
PiperOrigin-RevId: 804711466
Merge https://github.com/google/adk-python/pull/1629
close https://github.com/google/adk-python/issues/2170
### Summary
This PR introduces `GkeCodeExecutor`, a new code executor that provides a secure and scalable method for running LLM-generated code by leveraging GKE Sandbox. It serves as a robust alternative to local or standard containerized executors by leveraging the **GKE Sandbox** environment, which uses gVisor for workload isolation.
For each code execution request, it dynamically creates an ephemeral Kubernetes Job with a hardened Pod configuration, offering significant security benefits and ensuring that each code execution runs in a clean, isolated environment.
### Key Features of GkeCodeExecutor
* **Dynamic Job Creation**: Uses the Kubernetes `batch/v1` API to create a new Job for each code snippet.
* **Secure Code Mounting**: Injects code into the Pod via a temporary `ConfigMap`, which is mounted to a read-only file.
* **gVisor Sandboxing**: Enforces execution within a `gvisor` runtime for kernel-level isolation.
* **Hardened Security Context**: Pods run as non-root with all Linux capabilities dropped and a read-only root filesystem.
* **Resource Management**: Applies configurable CPU and memory limits to prevent abuse.
* **Automatic Cleanup**: Uses the `ttl_seconds_after_finished` feature on Jobs for robust, automatic garbage collection of completed Pods and Jobs.
* **Node Scheduling**: The executor uses Kubernetes `tolerations` in its Pod specification. This allows the k8s scheduler to place the execution Pod onto a **_pre-configured_** gVisor-enabled node.
* **Module Integration**: The `GkeCodeExecutor` is registered in the `code_executors/__init__.py`, making it available for use by agents. The `ImportError` handling is configured to check for the required `kubernetes` SDK.
### Execution Flow:
1. Agent invokes `GkeCodeExecutor` with the LLM-generated code.
2. The `GkeCodeExecutor` will `execute_code` – creates a temporary `ConfigMap`, and then create a k8s `Job` to run it.
3. This Job runs a standard `python:3.11-slim` container. The image is pulled once to the node and cached. The Job will mount the ConfigMap as `/app/code.py`
4. The GkeCodeExecutor will monitor the Job to completion, fetch `stdout/stderr` logs from the container, return `CodeExecutionResult` to the LlmAgent, and ensure all temp resources are deleted.
5. The calling agent formats the result and provides a final response to the user. If the result contains error, it will retry up to `error_retry_attempts` times.
PiperOrigin-RevId: 804511467
Introduce `DynamicPickleType` to handle session actions, using sqlalchemy-spanner `SpannerPickleType` when the database dialect is Spanner.
Connects to a Spanner database to store session data persistently in tables.
# Example using Spanner database:
`session_service = DatabaseSessionService(db_url="spanner+spanner:///projects/project-id/instances/instance-id/databases/database-id")`
# Example adk web command:
`adk web --session_service_uri="spanner+spanner:///projects/project-id/instances/instance-id/databases/database-id"`
PiperOrigin-RevId: 797416610
This change keeps dependencies to their major versions, but for the pre 1.0.0 releases pinned to minor releases as they could have breaking changes.
PyYAML: Version 7.0 is in development and could have breaking changes
absolufy-imports: The package is archived and no longer maintained.
anyio: Follows SemVer, so version 5.0 could have breaking changes.
authlib: Follows a SemVer-like pattern, so version 2.0 could have breaking changes.
click: A mature library, version 9.0 is the expected boundary for breaking changes.
fastapi: As a pre-1.0 library, the next minor release could have breaking changes.
google-api-python-client: Although in maintenance, version 3.0 could still have breaking changes.
google-cloud-aiplatform: Follows SemVer, so breaking changes are expected in version 2.0.
google-cloud-secret-manager: A stable Google library, version 3.0 could lead to breaking changes.
google-cloud-speech: A stable Google library, version 3.0 could lead to breaking changes.
google-cloud-storage: A stable Google library.
google-genai: As an official Google SDK, version 2.0 is the expected boundary for breaking changes.
graphviz: As a pre-1.0 library, the next minor release could have breaking changes.
mcp: As an SDK, version 2.0 is the boundary for potential breaking changes.
opentelemetry-api: Follows SemVer; version 2.0 could have breaking changes.
opentelemetry-exporter-gcp-trace: It's tied to the v1 OpenTelemetry API, so version 2.0 would likely be a breaking change.
opentelemetry-sdk: It's coupled to the v1 API, so version 2.0 would likely be a breaking change.
pydantic: This stops upgrades to the incompatible version 3.0 after its major 2.0 rewrite.
python-dateutil: Follows to SemVer, making version 3.0 the boundary for potential breaking changes.
python-dotenv: Locks to stable version 1.0 major release.
requests: As a more mature library, version 3.0 is boundary for breaking changes.
sqlalchemy: This locks the dependency to the stable version 2.0 API after its major rewrite.
starlette: As a pre-1.0 library, the next minor release could have breaking changes.
tenacity: This is a mature library, version 9.0 is boundary for breaking changes.
typing-extensions: Major versions are tied to large typing changes in Python itself.
tzlocal: The library has a history of introducing breaking API changes between major versions.
uvicorn: As a pre-1.0 library, the next minor release could have breaking changes.
watchdog: As a stable library, version 7.0 could have breaking changes.
websockets: Follows SemVer, so version 16.0 is the boundary for breaking changes.
PiperOrigin-RevId: 794677571
Spanner toolset support basic operations to interact with Spanner table metadata and query results.
Consolidate BigQueryTool into generic GoogleTool, so that BigQueryToolset and SpannerToolset can share.
PiperOrigin-RevId: 794259782