Okay, so not “Gemini Code Assist” but sufficiently similar that I think it warrants the “3/3” appellation.

I’m not a huge fan of all the se Node.JS-based CLI tools but, Google has released Gemini CLI. It’s good to have a CLI-based tool and it feels otherwise similar to the “Gemini Code Assist” chat.

I don’t (want to) run Node.JS on my Linux host and so am using the containerized version of the CLI here. It’s all documented on the gemini-cli repo but the auth functionality is sub-optimal (see [#1437] ) and you’ll want to use an API key if you can (see below):

Solved!

Ugh.

Before I continue, one important detail from yesterday’s experience which I think I didn’t clarify is that, unlike the Copilot agent, it appears (!?) that Gemini agent only supports integration with MCP servers via stdio. As a result, the only way to integrate with HTTP-based MCP servers (local or remote) is to proxy traffic through stdio as mcp-remote and the Rust example herein.

The most helpful change was to take a hint from the NPM mcp-remote and create a log file. This helps because, otherwise the mcp-remote process, because it’s launched by Visual Studio Code, well Gemini Code Assist agent, isn’t trivial to debug.

Former Microsoftie and Googler:

Good documentation Extend your agent with Model Context Protocol

Not such good documentation: Using agentic chat as a pair programmer

Definition of “good” being, I was able to follow the clear instructions and it worked first time. Well done, Microsoft!

This space is moving so quickly and I’m happy to alpha test these companies’ solutions but (a) Google’s portfolio is a mess. This week I’ve tried (and failed) to use Gemini CLI (because I don’t want to run Node.JS on my host machine and it doesn’t work in a container: issue #1437) and now this.

Responded to Get Custom K8s Resource using Python and found the CustomObjectsApi documentation unclear.

If you have a cluster and a kubeconfig file with a correctly configured current-context, so that you can successfully:

PLURAL="checks"

kubectl get ${PLURAL} \
--all-namespaces

NOTE I’m using Ackal’s CRDs in these examples.

Then you can use the following code to access the cluster’s REST API server to enumerate its CRDs:

main.py:

from __future__ import print_function
from kubernetes import client, config
from kubernetes.client.rest import ApiException

config.load_kube_config()
api = client.CustomObjectsApi()

# Ackal's Group|Version and some Kinds
group = 'ack.al'
version = 'v1'
plurals = ['checks','customers']

for plural in plurals:
    try:
        resp = api.list_cluster_custom_object(
            group,
            version,
            plural,
        )

        for item in resp["items"]:
            spec = item["spec"]
            print(spec)
    except ApiException as e:
        print(e)

python3 -m venv venv
source venv/bin/activate
python3 -m pip install kubernetes==26.1.0
python3 main.py

That’s all!

The majority of Ackal’s components are deployed to Google Cloud. However, by its nature, Ackal benefits from deployments that span cloud platforms. I’ve deployed Ackal’s gRPC health checks to Fly, and managed Kubernetes services on Linode and Vultr.

Today, I decided to revisit¹ Azure. Ackal uses Azure (Active Directory) for one of its OAuth providers. This time, I wanted to deploy a containerized gRPC service. Azure provides several container-oriented services. I decided to use Azure Container Apps and, in hindsight, find it analogous to Google Cloud Run.