feat: Add cloud deployment example with event replication #387
Conversation
Add Kubernetes deployment example demonstrating multi-instance A2A agents with database persistence and Kafka-based event replication.
Summary of ChangesHello @kabir, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request delivers a robust, end-to-end example for deploying an A2A agent in a cloud-native environment using Kubernetes. It illustrates key architectural patterns for scalable and resilient agent deployments, including load distribution, shared state management via a database, and real-time event synchronization across instances using Kafka. The example is fully runnable on Minikube and comes with detailed instructions and verification steps. Highlights
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a cloud deployment example for the A2A agent using Kubernetes, PostgreSQL for task persistence, and Kafka for event replication. The changes include a README with setup instructions, Kubernetes manifests, deployment scripts, and a test client. The review focuses on identifying potential issues related to the deployment process, resource configurations, and overall clarity of the documentation.
examples/cloud-deployment/README.md
Outdated
|
|
||
| ### 1. Start Minikube | ||
|
|
||
| This example uses a local container registry on the host machine. Minikube must be configured to allow pulling from this insecure (HTTP) registry. |
There was a problem hiding this comment.
Consider adding a note about the importance of using the host network driver in Minikube for this example to work correctly, as the local registry is accessed via the host's IP.
| - Kafka not ready: Kafka takes 2-5 minutes to start fully | ||
| - Wait for `kubectl wait --for=condition=Ready kafka/a2a-kafka -n a2a-demo` |
There was a problem hiding this comment.
It might be helpful to include instructions on how to verify that topics are created successfully, potentially using kubectl exec into a Kafka pod and using the Kafka command-line tools.
| MAX_RETRIES=3 | ||
| for attempt in $(seq 1 $MAX_RETRIES); do | ||
| echo "Push attempt $attempt/$MAX_RETRIES..." | ||
| if $CONTAINER_TOOL push ${REGISTRY}/a2a-cloud-deployment:latest --tls-verify=false --retry=2 2>&1 | tee /tmp/push.log; then |
There was a problem hiding this comment.
Consider adding --all-namespaces to the kubectl get commands to check for the Strimzi operator in all namespaces, in case the user has installed it in a different namespace than kafka.
| MAX_RETRIES=3 | ||
| for attempt in $(seq 1 $MAX_RETRIES); do | ||
| echo "Push attempt $attempt/$MAX_RETRIES..." | ||
| if $CONTAINER_TOOL push ${REGISTRY}/a2a-cloud-deployment:latest --tls-verify=false --retry=2 2>&1 | tee /tmp/push.log; then |
There was a problem hiding this comment.
The --tls-verify=false flag is used when pushing the image. This disables TLS verification, which is insecure and should be avoided in production environments. Since this is a development example using a self-signed certificate, it's acceptable, but a comment explaining why it's needed and the security implications would be helpful.
Consider adding a comment explaining the use of --tls-verify=false and the security implications.
| MAX_RETRIES=3 | ||
| for attempt in $(seq 1 $MAX_RETRIES); do | ||
| echo "Push attempt $attempt/$MAX_RETRIES..." | ||
| if $CONTAINER_TOOL push ${REGISTRY}/a2a-cloud-deployment:latest --tls-verify=false --retry=2 2>&1 | tee /tmp/push.log; then |
There was a problem hiding this comment.
The push command includes --retry=2. This is good for handling transient network issues, but it might be beneficial to add a comment explaining why retries are needed and under what circumstances they might occur (e.g., flaky network in Minikube).
| containers: | ||
| - name: a2a-agent | ||
| image: 192.168.49.1:5001/a2a-cloud-deployment:latest | ||
| imagePullPolicy: Always |
There was a problem hiding this comment.
Using imagePullPolicy: Always can cause unnecessary image pulls if the image tag is :latest. It might be better to use IfNotPresent for development to reduce image pull frequency, and Always for production with specific image tags.
| if (attempt > 1) { | ||
| System.out.println("Retry attempt " + attempt + "/" + maxRetries + "..."); | ||
| Thread.sleep(1000); // Wait for Kafka events to propagate | ||
| } |
There was a problem hiding this comment.
Consider adding a small delay before retrying the subscription to allow Kafka events to propagate. This can help avoid transient errors when the Kafka cluster is still initializing.
| Client freshClient = Client.builder(streamingClient.getAgentCard()) | ||
| .clientConfig(nonStreamingConfig) | ||
| .withTransport(JSONRPCTransport.class, new JSONRPCTransportConfigBuilder()) | ||
| .build(); |
There was a problem hiding this comment.
Creating a new client for each request can be resource-intensive. Consider using a connection pool or reusing clients where possible to improve performance.
| if (!completionLatch.await(10, TimeUnit.SECONDS)) { | ||
| System.err.println("⚠ Timeout waiting for task completion"); |
There was a problem hiding this comment.
The timeout for task completion is set to 10 seconds. In some environments, tasks might take longer to complete. Consider making this timeout configurable or increasing it to handle slower task processing.
| <packaging>pom</packaging> | ||
|
|
||
| <name>Java SDK A2A Examples</name> | ||
| <name>Java SDK A2A Examples: Hello World</name> |
There was a problem hiding this comment.
The description is too generic. Consider updating the description to be specific to the Hello World example.
| <name>Java SDK A2A Examples: Hello World</name> | |
| <name>Java SDK A2A Examples: Hello World</name> | |
| <description>A simple Hello World example for the Java SDK for the Agent2Agent Protocol (A2A)</description> |
Replace external registry container approach with Minikube's built-in registry addon for improved cross-platform compatibility. Key changes: - Use 'minikube addons enable registry' instead of external container - Port-forward to localhost:5000 (macOS: socat, Linux: kubectl) - Update image reference from 192.168.49.1:5001 to localhost:5000 - Change imagePullPolicy from Always to IfNotPresent - Remove insecure-registry requirement from Minikube start - Simplify GitHub Actions workflow Benefits: - Works with rootless Podman on Fedora/Linux - No insecure registry configuration needed - Cross-platform consistency (Mac, Linux, Windows) - Follows proven WildFly cloud-tests patterns - Simpler setup and troubleshooting Fixes compatibility issues with rootless Podman where external registry running in user context was inaccessible from Minikube VM.
|
Replaced by #389 |
1 participant
Add Kubernetes deployment example demonstrating multi-instance A2A agents with database persistence and Kafka-based event replication.
Fixes #281 and #373