Update docs links and Calico v3.15 references

README.md

@@ -60,7 +60,7 @@ In this workshop we are going to focus on these main use cases (with links to Ca
     >Whether you’ve finished with your Calico Cloud Trial or decided to disconnect your cluster from Calico Cloud, we know you want your cluster to remain functional. We highly recommend running a simple script to migrate your cluster to open-source Project Calico.
 
     ```bash
-    curl -O https://installer.calicocloud.io/manifests/v3.14.1-1/downgrade.sh
+    curl -O https://installer.calicocloud.io/manifests/v3.15.1-8/downgrade.sh
     ```
 
     ```bash
@@ -75,7 +75,7 @@ In this workshop we are going to focus on these main use cases (with links to Ca
 
     ```bash
     kubectl delete -f demo/dev/app.manifests.yaml
-    kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/master/release/kubernetes-manifests.yaml
+    kubectl delete -f https://raw.githubusercontent.com/googlecloudplatform/microservices-demo/v0.3.8/release/kubernetes-manifests.yaml
     ```
 
 3. Delete AKS cluster.

modules/anomaly-detection.md

@@ -4,7 +4,7 @@
 
 ---
 
-Calico offers [Anomaly Detection](https://docs.tigera.io/threat/security-anomalies) (AD) as a part of its [threat defense](https://docs.tigera.io/threat/) capabilities. Calico's Machine Learning algorithms can baseline "normal" traffic patterns and subsequently detect abnormal or suspicious behavior. This may resemble an Indicator of Compromise and will generate a security alert to take further action on the incident.
+Calico offers [Anomaly Detection](https://docs.tigera.io/calico-cloud/threat/security-anomalies) (AD) as a part of its [threat defense](https://docs.tigera.io/calico-cloud/threat/) capabilities. Calico's Machine Learning algorithms can baseline "normal" traffic patterns and subsequently detect abnormal or suspicious behavior. This may resemble an Indicator of Compromise and will generate a security alert to take further action on the incident.
 
 ## Steps
 

modules/creating-aks-cluster.md

@@ -118,20 +118,20 @@ Follow the prerequisite steps if you need to verify your Azure subscription and
 
     ```text
     KubernetesVersion    Upgrades
-    -------------------  ------------------------
-    1.24.0(preview)      None available
-    1.23.8               1.24.0(preview)
-    1.23.5               1.23.8, 1.24.0(preview)
-    1.22.11              1.23.5, 1.23.8
-    1.22.6               1.22.11, 1.23.5, 1.23.8
-    1.21.14              1.22.6, 1.22.11
-    1.21.9               1.21.14, 1.22.6, 1.22.11
+    -------------------  -----------------------
+    1.26.0(preview)      None available
+    1.25.5               1.26.0(preview)
+    1.25.4               1.25.5, 1.26.0(preview)
+    1.24.9               1.25.4, 1.25.5
+    1.24.6               1.24.9, 1.25.4, 1.25.5
+    1.23.15              1.24.6, 1.24.9
+    1.23.12              1.23.15, 1.24.6, 1.24.9
     ```
 
-    For this lab we'll use 1.22.11
+    For this lab we'll use 1.25.5
 
     ```bash
-    K8SVERSION=1.22.11
+    K8SVERSION=1.25.5
     echo export K8SVERSION=$K8SVERSION >> ~/.bashrc
     ```
 
@@ -157,7 +157,7 @@ Follow the prerequisite steps if you need to verify your Azure subscription and
     ```bash
     Name                 Location    ResourceGroup      KubernetesVersion    ProvisioningState    Fqdn
     -------------------  ----------  -----------------  -------------------  -------------------  ----------------------------------------------------------------
-    aks-calicocloud-repo    eastus      aks-rg-jessie    1.22.11               Succeeded            aks-calico-aks-rg-jessie-03cfb8-b45d6762.hcp.eastus.azmk8s.io
+    aks-calicocloud-repo    eastus      aks-rg-jessie    1.25.5              Succeeded            aks-calico-aks-rg-jessie-03cfb8-b45d6762.hcp.eastus.azmk8s.io
     ```
 
 5. Get the Kubernetes config files for your new AKS cluster
@@ -176,9 +176,9 @@ Follow the prerequisite steps if you need to verify your Azure subscription and
 
     ```bash
     NAME                                STATUS   ROLES   AGE   VERSION
-    aks-nodepool1-36555681-vmss000000   Ready    agent   47m   v1.22.11
-    aks-nodepool1-36555681-vmss000001   Ready    agent   47m   v1.22.11
-    aks-nodepool1-36555681-vmss000002   Ready    agent   47m   v1.22.11
+    aks-nodepool1-36555681-vmss000000   Ready    agent   47m   v1.25.5
+    aks-nodepool1-36555681-vmss000001   Ready    agent   47m   v1.25.5
+    aks-nodepool1-36555681-vmss000002   Ready    agent   47m   v1.25.5
 
     ```
 

modules/layer7-logging.md

@@ -4,7 +4,7 @@
 
 ---
 
-Calico Cloud can be enabled for Layer 7 application visibility which captures the HTTP calls applications are making. Application visibility does not require a service mesh but does utilize envoy for capturing logs. Envoy is deployed as part of an L7 Log Collector DaemonSet per Kubernetes node - this requires less resources than a sidecar per pod. For more info please review the [documentation](https://docs.tigera.io/visibility/elastic/l7/configure).
+Calico Cloud can be enabled for Layer 7 application visibility which captures the HTTP calls applications are making. Application visibility does not require a service mesh but does utilize envoy for capturing logs. Envoy is deployed as part of an L7 Log Collector DaemonSet per Kubernetes node - this requires less resources than a sidecar per pod. For more info please review the [documentation](https://docs.tigera.io/calico-cloud/visibility/elastic/l7/configure).
 
 ## Steps
 

modules/packet-capture.md

@@ -2,7 +2,7 @@
 
 **Goal:** Configure packet capture for specific pods and review captured payload.
 
-Packet captures are Kubernetes Custom Resources and thus native Kubernetes RBAC can be used to control which users/groups can run and access Packet Captures; this may be useful if Compliance or Governance policies mandate strict controls on running Packet Captures for specific workloads. This demo is simplified without RBAC but further details can be found [here](https://docs.tigera.io/visibility/packetcapture#enforce-rbac-for-packet-capture).
+Packet captures are Kubernetes Custom Resources and thus native Kubernetes RBAC can be used to control which users/groups can run and access Packet Captures; this may be useful if Compliance or Governance policies mandate strict controls on running Packet Captures for specific workloads. This demo is simplified without RBAC but further details can be found [here](https://docs.tigera.io/calico-cloud/visibility/packetcapture#enforce-rbac-for-capture-tasks-for-cli-users).
 
 ## Steps
 

modules/using-alerts.md

@@ -39,7 +39,7 @@
 
 4. Trigger GlobalThreatfeed from known bad actors.
 
-    Calico Cloud offers [Global threat feed](https://docs.tigera.io/reference/resources/globalthreatfeed) resource to prevent known bad actors from accessing Kubernetes pods.
+    Calico Cloud offers [Global threat feed](https://docs.tigera.io/calico-cloud/reference/resources/globalthreatfeed) resource to prevent known bad actors from accessing Kubernetes pods.
 
     ```bash
     kubectl get globalthreatfeeds

modules/using-compliance-reports.md

@@ -22,7 +22,7 @@
 
     >If you don't see any reports, you can manually kick off report generation task. Follow the steps below if you need to do so.
 
-    Calico provides `GlobalReport` resource to offer [Compliance reports](https://docs.tigera.io/compliance/overview) capability. There are several types of reports that you can configure:
+    Calico provides `GlobalReport` resource to offer [Compliance reports](https://docs.tigera.io/calico-cloud/compliance/overview) capability. There are several types of reports that you can configure:
 
     - CIS benchmarks
     - Inventory
@@ -43,7 +43,7 @@
 
    a. Review and apply the yaml file for the managed cluster.
 
-    Instructions below for a Managed cluster only. Follow [configuration documentation](https://docs.tigera.io/compliance/overview#run-reports) to configure compliance jobs for management and standalone clusters. We will need change the START/END time accordingly.
+    Instructions below for a Managed cluster only. Follow [configuration documentation](https://docs.tigera.io/calico-cloud/compliance/overview#run-reports) to configure compliance jobs for management and standalone clusters. We will need change the START/END time accordingly.
 
     ```bash
     vi demo/40-compliance-reports/compliance-reporter-pod.yaml
@@ -79,7 +79,7 @@
 
     Once the `run-reporter` job finished, you should be able to see this report in manager UI and download the csv file.
 
-3. Reports are generated 30 minutes after the end of the report as [documented](https://docs.tigera.io/compliance/overview#change-the-default-report-generation-time). As the compliance reports deployed in the [manifests](https://github.com/tigera-solutions/calicocloud-aks-workshop/tree/main/demo/40-compliance-reports) are scheduled to run every 10 minutes the generation of reports will take between 30-60 mins depending when the manifests were deployed.
+3. Reports are generated 30 minutes after the end of the report as [documented](https://docs.tigera.io/calico-cloud/compliance/overview#change-the-default-report-generation-time). As the compliance reports deployed in the [manifests](https://github.com/tigera-solutions/calicocloud-aks-workshop/tree/main/demo/40-compliance-reports) are scheduled to run every 10 minutes the generation of reports will take between 30-60 mins depending when the manifests were deployed.
 
 <br>