skill-based updates

Author: anupras-mohapatra-arm

content/learning-paths/servers-and-cloud-computing/storefront-ai-assistant-gke-axion/_index.md

@@ -1,19 +1,21 @@
 ---
-title: Build a mixed-placement AI shopping assistant on Google Kubernetes Engine with Axion-based compute
+title: Deploy a mixed-placement AI shopping assistant on Google Kubernetes Engine with Axion-based compute
 
 minutes_to_complete: 120
-description: Deploy and validate an Online Boutique storefront on GKE, add an AI shopping assistant, and compare N4A and C4A placement for the assistant tier.
+description: Deploy and validate an Online Boutique storefront on GKE on Arm, add an AI shopping assistant, and compare N4A and C4A placement for the assistant tier.
 who_is_this_for: This is an advanced topic for cloud developers, platform engineers, and site reliability engineers who run applications on Google Kubernetes Engine (GKE) and want to place application tiers on the Axion-based machine series that fits each workload.
 
 learning_objectives:
-    - Create and validate an Online Boutique storefront on an N4A node pool
+    - Deploy and validate an Online Boutique storefront on an N4A node pool
     - Build and push a `linux/arm64` container image, then add the AI shopping assistant to the storefront
     - Use Kustomize overlays to run the assistant on N4A first, then move it to C4A
     - Capture and compare benchmark summaries for the same assistant workload on N4A and C4A
 
 prerequisites:
     - A [Google Cloud account](https://console.cloud.google.com/) with billing enabled
-    - Access to a [GKE Standard cluster with Arm node pools](https://cloud.google.com/kubernetes-engine/docs/how-to/create-arm-clusters-nodes), including N4A and C4A node pools
+    - Access to a [GKE Standard cluster with Arm node pools](https://cloud.google.com/kubernetes-engine/docs/how-to/create-arm-clusters-nodes), including N4A and C4A node pools, with the Kubernetes Metrics API enabled
+    - Permissions to get cluster credentials, deploy Kubernetes workloads and services, read pod logs and metrics, and create or use an Artifact Registry Docker repository
+    - Cloud Shell or a Linux or macOS administrative workstation with Docker Buildx, `gcloud`, `kubectl`, `git`, `curl`, Python 3.10 or later, and `jq`
     - Basic familiarity with Docker, Kubernetes, Kustomize, and GKE
 
 author:

content/learning-paths/servers-and-cloud-computing/storefront-ai-assistant-gke-axion/background.md

@@ -15,17 +15,16 @@ The goal isn't to prove that one Axion-based machine series replaces the other.
 
 ![Architecture diagram showing the existing multi-architecture storefront image workflow and the final GKE placement on Axion. Core storefront services run on N4A, while the shopping assistant, Ollama sidecar, and Gemma model run together on C4A and call the live cart and catalog services.#center](images/mixed-placement-agentic-storefront-on-axion.webp "Mixed-placement agentic storefront on Axion")
 
-The diagram shows the final mixed-placement pattern you'll build toward. Its left side summarizes the multi-architecture image publishing process used for the existing storefront images; you don't repeat that process here. The assistant image you'll build later targets only `linux/arm64` because both destination node pools are Arm-based. The right side shows the final placement: core services remain on N4A while the assistant, its Ollama sidecar, and the Gemma model move together to C4A.
+The diagram shows the final mixed-placement pattern you'll build toward. It summarizes the multi-architecture image publishing process used for the existing storefront images; you don't repeat that process here. The assistant image you'll build later targets only `linux/arm64` because both destination node pools are Arm-based. The diagram also shows the final placement: core services remain on N4A while the assistant, its Ollama sidecar, and the Gemma model move together to C4A.
 
 ## How the storefront already runs on Arm
 
 The storefront baseline uses container images that can run on Arm nodes. A common way to publish portable container images is to use a multi-architecture image, which is one image reference that contains variants for more than one CPU architecture, such as `linux/amd64` and `linux/arm64`.
 
-When Kubernetes schedules a pod that uses a multi-architecture image on an Arm node, the container runtime pulls the Arm-compatible variant from the same image reference. That's why the storefront can already run on Axion nodes before you build the assistant image.
+When Kubernetes schedules a pod that uses a multi-architecture image on an Arm node, the container runtime pulls the Arm-compatible variant from the same image reference. That's why the storefront can already run on Axion nodes before you build the assistant image. You'll confirm the storefront image reference from the source tree after you set up your tools and cluster access.
 
 You'll start with Arm-compatible storefront images already available. To learn the full build-and-publish workflow for multi-architecture images on GKE, see [Migrate x86 workloads to Arm on Google Kubernetes Engine with Axion processors](/learning-paths/servers-and-cloud-computing/gke-multi-arch-axion/).
 
-One image reference can therefore contain an Arm-compatible variant. You'll confirm the storefront image reference from the source tree after you set up your tools and cluster access.
 
 ## How assistant requests flow
 
@@ -47,6 +46,6 @@ This design keeps the placement comparison focused. You don't add a separate vec
 
 ## What you've learned and what's next
 
-You've now understood the architecture of the storefront application and its AI assistant.
+You've now learned about the architecture of the storefront application and its AI assistant.
 
 Next, you'll set up environment variables, connect to the GKE cluster, and clone the source tree that contains the assistant implementation.

content/learning-paths/servers-and-cloud-computing/storefront-ai-assistant-gke-axion/deploy-assistant-n4a.md

@@ -99,7 +99,7 @@ The `server` container serves the assistant API. The `ollama` container prepares
 The first rollout can take a few minutes because the Ollama sidecar pulls the model when the pod starts. Early `/readyz` checks can return `503` until the model is available.
 {{% /notice %}}
 
-## Send a request in one assistant session
+## Send a request through one assistant session
 
 Open the assistant endpoint and save its HTTP session cookie in `/tmp/assistant.cookies`. The next request sends the same cookie back, just as a browser would. The assistant can then associate follow-up prompts and cart actions with the same short-lived session.
 
@@ -136,7 +136,7 @@ yes
 What is in my cart now?
 ```
 
-The assistant recommends a catalog item, ask for confirmation before changing the cart, and then show the cart contents.
+The assistant recommends a catalog item and asks for confirmation before changing the cart. It then shows the cart's contents.
 
 ## What you've accomplished and what's next
 

content/learning-paths/servers-and-cloud-computing/storefront-ai-assistant-gke-axion/move-assistant-c4a.md

@@ -171,7 +171,7 @@ python3 workshop/compare_summaries.py \
   sed '/^Interpretation$/,$d'
 ```
 
-This displays the measured comparison table without adding a predetermined placement conclusion. Lower batch duration and request latency indicate the faster run for those measurements.
+This displays the measured comparison table without forcing a predetermined placement conclusion. Lower batch duration and request latency indicate the faster run for those measurements.
 
 Focus on these signals:
 

content/learning-paths/servers-and-cloud-computing/storefront-ai-assistant-gke-axion/observe-benchmark-n4a.md

@@ -1,6 +1,6 @@
 ---
 title: Observe and benchmark the assistant on N4A
-description: Start the telemetry dashboard, generate assistant traffic, and capture a fixed N4A benchmark summary.
+description: Start the telemetry dashboard, generate assistant traffic, and capture a fixed-batch N4A benchmark summary.
 weight: 8
 layout: "learningpathall"
 ---
@@ -15,7 +15,7 @@ The source tree includes helper scripts that focus traffic and telemetry on the
 - `workshop/fixed_batch_trial.py` runs a repeatable benchmark.
 - `workshop/compare_summaries.py` compares benchmark summaries.
 
-Compile the scripts before you run them:
+Check the assistant service and compile the scripts before you run them:
 
 ```bash
 kubectl get deployment shoppingassistantservice

content/learning-paths/servers-and-cloud-computing/storefront-ai-assistant-gke-axion/project-setup.md

@@ -53,7 +53,7 @@ fi
 docker buildx inspect --bootstrap
 ```
 
-Confirm that the `Platforms` line includes `linux/arm64` before you continue. The later build command uses this capability to produce an image for the Arm-based N4A and C4A nodes. If `linux/arm64` is missing, configure Arm support for your Docker builder before continuing.
+Confirm that the `Platforms` line includes `linux/arm64` before you continue. The later build command uses this capability to produce an image for the Arm-based N4A and C4A nodes. If `linux/arm64` is missing, configure Arm support for your Docker builder before continuing. For more information, see [Build multi-architecture images with Docker buildx](/learning-paths/cross-platform/docker/buildx/).
 
 You'll also use Kustomize in the following sections. Kustomize combines a shared set of Kubernetes manifests with reusable components and placement-specific patches. The tool is built into `kubectl`, so the `kubectl kustomize` and `kubectl apply -k` commands don't need a separate Kustomize executable.
 
@@ -143,7 +143,7 @@ kubectl config current-context
 kubectl get nodes
 ```
 
-## Confirm the Artifact Registry repository
+## Create or confirm the Artifact Registry repository
 
 The assistant image is pushed to Artifact Registry. Create the Docker repository if it doesn't already exist:
 
@@ -195,7 +195,7 @@ The commit should be:
 b0a1be98cd47087638b2ea98c9c3de01bc4f533c
 ```
 
-## Confirm the Arm foundation
+## Confirm Arm node pools and storefront images
 
 Check that the cluster has Arm node pools for N4A and C4A:
 

content/learning-paths/servers-and-cloud-computing/storefront-ai-assistant-gke-axion/validate-n4a-baseline.md

@@ -138,7 +138,7 @@ Send a header request to the storefront:
 curl --max-time 30 -I "${APP_URL}"
 ```
 
-The output should include an HTTP response header. A `200 OK` or `302 Found` response confirms that the baseline storefront is reachable.
+The output includes an HTTP response header. A `200 OK` or `302 Found` response confirms that the baseline storefront is reachable.
 
 Open the printed URL in your browser to load the Online Boutique storefront.