diff --git a/content/learning-paths/cross-platform/_example-learning-path/_index.md b/content/learning-paths/cross-platform/_example-learning-path/_index.md index c9e6588889..579cb98d98 100644 --- a/content/learning-paths/cross-platform/_example-learning-path/_index.md +++ b/content/learning-paths/cross-platform/_example-learning-path/_index.md @@ -18,7 +18,7 @@ prerequisites: author: Zach Lasiuk -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/benchmark-nlp/_index.md b/content/learning-paths/servers-and-cloud-computing/benchmark-nlp/_index.md index 52d3c82d07..ec105d7b67 100644 --- a/content/learning-paths/servers-and-cloud-computing/benchmark-nlp/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/benchmark-nlp/_index.md @@ -14,9 +14,55 @@ learning_objectives: prerequisites: - An [Arm-based instance](/learning-paths/servers-and-cloud-computing/csp/) from a cloud service provider or an on-premise Arm server. +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:36:51Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: a4cf1d9161b3a32e29694415762eda419752e1c3144662d5e131b6553f0a58e3 + summary_generated_at: '2026-06-30T21:36:51Z' + summary_source_hash: a4cf1d9161b3a32e29694415762eda419752e1c3144662d5e131b6553f0a58e3 + faq_generated_at: '2026-06-30T21:36:51Z' + faq_source_hash: a4cf1d9161b3a32e29694415762eda419752e1c3144662d5e131b6553f0a58e3 + summary: >- + You'll deploy Hugging Face Sentiment Analysis models + with PyTorch on Arm servers and measure how they perform. Starting from a working Ubuntu + 22.04 Arm environment, you'll run three NLP models with the Sentiment Analysis + pipeline, record baseline results, and enable BFloat16 fast math kernels to assess the + impact on inference performance. By + the end, you'll compare before-and-after measurements to confirm the effect of BFloat16 + on this workload. + faqs: + - question: Which environment do the instructions assume? + answer: >- + The instructions target an Arm server running Ubuntu 22.04 LTS. They've been tested on + AWS Graviton3 (c7g) instances. + - question: What system resources should I provision before running the steps? + answer: >- + Use an Arm server instance with at least four CPU cores and 8 GB of RAM. This capacity supports + running the three sentiment analysis models and collecting measurements. + - question: Which framework and model source will I use in this Learning Path? + answer: >- + You'll uses PyTorch to run NLP Sentiment Analysis models sourced from Hugging Face. + - question: How should I measure the performance uplift from BFloat16 fast math kernels? + answer: >- + First, run the models to collect a baseline using the same Sentiment Analysis pipeline. + Then enable BFloat16 fast math kernels on supported Arm Neoverse-based AWS Graviton3 processors, + rerun the same workload, and compare measurements. + - question: Which models will I evaluate and what should I have at the end? + answer: >- + You'll evaluate three NLP models with the Sentiment Analysis pipeline. By the end, you + should have deployed the models on your Arm server and recorded baseline and BFloat16-enabled + performance results for comparison. +# END generated_summary_faq + author: Pareena Verma -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/bitmap_scan_sve2/_index.md b/content/learning-paths/servers-and-cloud-computing/bitmap_scan_sve2/_index.md index a0b0ebb6e8..f4486198ee 100644 --- a/content/learning-paths/servers-and-cloud-computing/bitmap_scan_sve2/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/bitmap_scan_sve2/_index.md @@ -13,12 +13,59 @@ learning_objectives: - Measure performance improvements on Graviton4 instances prerequisites: -- An [Arm based instance](/learning-paths/servers-and-cloud-computing/csp/) from an appropriate - cloud service provider. +- An [Arm-based instance](/learning-paths/servers-and-cloud-computing/csp/) from an appropriate cloud service provider. + +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:37:19Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: 1701b37580fe5d012a5e6fd322307742656a748dfb766fd48914011167386e95 + summary_generated_at: '2026-06-30T21:37:19Z' + summary_source_hash: 1701b37580fe5d012a5e6fd322307742656a748dfb766fd48914011167386e95 + faq_generated_at: '2026-06-30T21:37:19Z' + faq_source_hash: 1701b37580fe5d012a5e6fd322307742656a748dfb766fd48914011167386e95 + summary: >- + You'll implement and benchmark bitmap scanning for database-style + workloads on Arm Neoverse V2–based servers, such as AWS Graviton4. First, you'll build a compact + bit vector in C and add baseline and improved scalar scanning routines. Then, you'll implement Neon + and SVE vectorized versions to process data in wider chunks. You'll use a benchmarking harness + that measures each approach so the relative behavior of scalar, Neon, and SVE implementations can + be compared on an Arm-based Linux instance. By the end, you'll run a single C program + that exercises all variants and produces timing results suitable for side-by-side evaluation. + faqs: + - question: Where should I place the code as I follow the steps? + answer: >- + Use a single source file named `bitvector_scan_benchmark.c`. Add the bit vector type, helper + functions, scalar scan routines, Neon and SVE implementations, and the benchmarking code + into this file as directed. + - question: What must the bitmap data structure contain before I can add the scan functions? + answer: >- + The data structure must include a byte array that holds the bits, the physical size in bytes, and the logical + size in bits. The same file must also add helpers to generate and analyze test bitmaps. + - question: In what order should I implement and test the scanning approaches? + answer: >- + Start with the per-bit scalar baseline, then the optimized scalar version, followed by the + Neon implementation, and finally SVE. After each addition, run the benchmark to compare + against the previous versions. + - question: What result should I expect from the benchmarking step? + answer: >- + The framework measures elapsed time for each scan function over a chosen number of iterations + and tracks how many set-bit positions were found. Use the same input bitmap and iteration + count when comparing implementations. + - question: How can I exercise different workload characteristics when benchmarking? + answer: >- + Use the provided bitmap generation helpers to create datasets with varying densities. Sparse + and dense bitmaps highlight different behaviors across the scalar, Neon, and SVE implementations. +# END generated_summary_faq author: Pareena Verma -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/bolt-demo/_index.md b/content/learning-paths/servers-and-cloud-computing/bolt-demo/_index.md index bac4423f6a..2e3c75d0f3 100644 --- a/content/learning-paths/servers-and-cloud-computing/bolt-demo/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/bolt-demo/_index.md @@ -20,9 +20,59 @@ prerequisites: - GCC version 13.3 or later to compile the example program ([GCC](/install-guides/gcc/) ) - A system with with sufficient hardware performance counters to use the [TopDown](/install-guides/topdown-tool) methodology. This typically requires running on bare metal rather than a virtualized environment. +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:37:54Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: 8654b656131bf1d529e11d85f874f7a81c01f7207340d2a606b6fd2d80bfad04 + summary_generated_at: '2026-06-30T21:37:54Z' + summary_source_hash: 8654b656131bf1d529e11d85f874f7a81c01f7207340d2a606b6fd2d80bfad04 + faq_generated_at: '2026-06-30T21:37:54Z' + faq_source_hash: 8654b656131bf1d529e11d85f874f7a81c01f7207340d2a606b6fd2d80bfad04 + summary: >- + You'll apply LLVM BOLT post-link optimization to AArch64 binaries + using profile-guided code layout. Starting with a deliberately inefficient BubbleSort workload + to make instruction locality issues visible, you'll install a suitable BOLT + release, set up a working directory, and gather profiles with BRBE, SPE, instrumentation, + or PMU sampling. Using a small set of Arm TopDown indicators, you'll judge + whether a program is front-end bound and a good candidate for BOLT. You'll then run BOLT with + collected profiles to reorganize code layout and evaluate the impact using performance + metrics and profiling data to confirm improvements in instruction delivery and locality. + faqs: + - question: Which BOLT version should I use if my package manager installs an older release? + answer: >- + Use LLVM BOLT 22.1.0 or later. If your distribution provides an older version, install a + prebuilt LLVM release instead (for example, LLVM 22.1.5) to match the required features. + - question: Where do the example’s build and profiling outputs go? + answer: >- + You'll find outputs in three directories: out for binaries, prof for profile data, + and heatmap for visualization artifacts. Keeping these separate makes it easier to rerun + steps and compare results. + - question: How do I know if my program is a good candidate for BOLT? + answer: >- + Check a small set of Arm TopDown indicators related to instruction delivery and code locality. + Programs that appear front-end bound, with inefficient instruction fetch and poor locality, + are strong candidates for code layout optimization with BOLT. + - question: What should I use if my kernel doesn't meet the BRBE or SPE requirements? + answer: >- + If your kernel is older than the BRBE requirement, use SPE if the kernel meets the SPE version + requirement. If neither is available, you can use instrumentation or PMU + event sampling to collect profiles. + - question: What result should I expect after running BOLT with profiles? + answer: >- + You should be able to evaluate changes using performance metrics and profiling data. Look + for improvements in instruction delivery indicators and evidence of better code locality + in the optimized binary. +# END generated_summary_faq + author: Paschalis Mpeis -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/bolt-merge/_index.md b/content/learning-paths/servers-and-cloud-computing/bolt-merge/_index.md index bbafc9268e..43294c673d 100644 --- a/content/learning-paths/servers-and-cloud-computing/bolt-merge/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/bolt-merge/_index.md @@ -16,9 +16,59 @@ learning_objectives: prerequisites: - An Arm-based Linux system with [BOLT](/install-guides/bolt/) and [Linux Perf](/install-guides/perf/) installed +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:38:23Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: 84a8b96fe7df302e0a2a6e4645bbb6170b45a3e0b55e0ea3682ec47663d34819 + summary_generated_at: '2026-06-30T21:38:23Z' + summary_source_hash: 84a8b96fe7df302e0a2a6e4645bbb6170b45a3e0b55e0ea3682ec47663d34819 + faq_generated_at: '2026-06-30T21:38:23Z' + faq_source_hash: 84a8b96fe7df302e0a2a6e4645bbb6170b45a3e0b55e0ea3682ec47663d34819 + summary: >- + You'll use BOLT with Linux Perf profiles to optimize an Arm application + and its shared libraries. First, you'll instrument a MySQL server build to generate workload-specific + profiles, create separate traces for read-heavy and write-heavy runs, and merge them to broaden + code layout guidance. Then, you'll rebuild OpenSSL to make `libssl.so` and + `libcrypto.so` suitable for BOLT, collect profiles, and apply optimizations independently + from the main binary. Finally, you'll compare results across baseline, isolated, and merged + scenarios using a consistent Sysbench configuration to assess the + impact of application and library-level optimizations on throughput and latency. + faqs: + - question: What output should I expect after running an instrumented workload with BOLT? + answer: >- + BOLT produces a profile file in `.fdata` format, such as `profile-writeonly.fdata`. These files + are later used to optimize the binary and can be merged to improve coverage. + - question: Should I reuse the BOLT-instrumented mysqld binary for additional workloads or create + a new one? + answer: >- + Either approach works. The steps allow reusing the previously instrumented binary or generating + a new instrumented variant as long as you produce a new `.fdata` profile for each workload. + - question: Which shared libraries are targeted for optimization, and what if the system copies + are stripped? + answer: >- + The path optimizes `libssl.so` and `libcrypto.so`. If system libraries are stripped, rebuild + OpenSSL from source with relocations enabled so BOLT can instrument and optimize them. + - question: Do I need to rebuild the application to benefit from optimized shared libraries? + answer: >- + The shared libraries are optimized independently of the application binary. The path focuses + on rebuilding OpenSSL for symbol information and then integrating the optimized libraries + with the application. + - question: What test configuration is used to compare baseline and BOLT-optimized results? + answer: >- + Sysbench is run with `--time=0 --events=10000` to complete exactly 10,000 requests per thread. + Use this consistent configuration to compare baseline, application-only, and merged-with-library + optimization scenarios. +# END generated_summary_faq + author: Gayathri Narayana Yegna Narayanan -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/bolt/_index.md b/content/learning-paths/servers-and-cloud-computing/bolt/_index.md index 44f98df34b..9d25538763 100644 --- a/content/learning-paths/servers-and-cloud-computing/bolt/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/bolt/_index.md @@ -1,5 +1,5 @@ --- -title: Learn how to optimize an application with BOLT +title: Optimize an application with BOLT description: Learn how to build, profile, and optimize Arm executables using BOLT post-link binary optimization to improve application performance through code layout improvements. minutes_to_complete: 30 @@ -15,9 +15,55 @@ prerequisites: - An Arm based system running Linux with [BOLT](/install-guides/bolt/) and [Linux Perf](/install-guides/perf/) installed. The Linux kernel should be version 5.15 or later. Earlier kernel versions can be used, but some Linux Perf features may be limited or not available. For [SPE](./bolt-spe) the version should be 6.14 or later. - (Optional) A second, more powerful Linux system to build the software executable and run BOLT. +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:38:54Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: 2e9ac8a3c73b7d3d59fe6ba20fb6d61fc2b7e5e9320aaadc20af0a8bbb3ff959 + summary_generated_at: '2026-06-30T21:38:54Z' + summary_source_hash: 2e9ac8a3c73b7d3d59fe6ba20fb6d61fc2b7e5e9320aaadc20af0a8bbb3ff959 + faq_generated_at: '2026-06-30T21:38:54Z' + faq_source_hash: 2e9ac8a3c73b7d3d59fe6ba20fb6d61fc2b7e5e9320aaadc20af0a8bbb3ff959 + summary: >- + You'll use BOLT to post-link optimize an Arm Linux executable + based on real execution profiles. First, you'll prepare a target system for profiling and optionally + a separate build/BOLT system, then choose a profiling method — Perf samples, ETM, or SPE — to + collect runtime behavior into a `perf.data` file. You'll convert the profile for BOLT, and run BOLT to reorder code layout and emit a new optimized executable. Finally, you'll compare the resulting binary against + the original to observe improvements. + faqs: + - question: How should I choose between Perf samples, ETM, and SPE for profiling? + answer: >- + Use the dedicated sections for each method. Perf samples provide general sampling data, + while ETM and SPE record richer branch information. Follow the method that best fits your + availability and profiling detail needs. + - question: Can I profile on one Arm Linux system and run BOLT on another? + answer: >- + Yes. The target system runs the application and collects the profile, and a separate Linux + system can build the application and run BOLT. Transfer the executable and the collected + profile files between systems as needed. + - question: What file should exist after recording with Perf before converting for BOLT? + answer: >- + Expect a `perf.data` file. Perf prints sample counts or data size when recording completes, + which indicates that profiling output was captured and is ready for conversion. + - question: What version of Perf do I need for the SPE workflow? + answer: >- + Use Linux Perf version 6.14 or later for SPE to capture the required branch stack information. + Verify the version before recording so the profile contains all needed fields. + - question: How do I check results after BOLT creates the optimized executable? + answer: >- + Run the same workload with the original and the optimized executables and compare outcomes. + The optimized executable should show improved performance relative to the original after + the steps are completed. +# END generated_summary_faq + author: Jonathan Davies -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/_index.md b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/_index.md index da34960cd2..34ef05a594 100644 --- a/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/buildkite-gcp/_index.md @@ -19,9 +19,57 @@ prerequisites: - Familiarity with [Docker](https://docs.docker.com/get-started/) and container concepts - A [GitHub account](https://github.com/join) to host your application repository +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:39:35Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: 4bda206717eef380430009f859826d9bcf820442d13492cd3c22a114561e2917 + summary_generated_at: '2026-06-30T21:39:35Z' + summary_source_hash: 4bda206717eef380430009f859826d9bcf820442d13492cd3c22a114561e2917 + faq_generated_at: '2026-06-30T21:39:35Z' + faq_source_hash: 4bda206717eef380430009f859826d9bcf820442d13492cd3c22a114561e2917 + summary: >- + You'll provision an Arm-based Google Cloud C4A virtual machine powered by Google + Axion, install Docker, Docker Buildx, and the Buildkite agent, and connect the agent to a + Buildkite queue. First, you'll create a small Flask application and Dockerfile in a GitHub repository, + then configure a Buildkite pipeline that uses Buildx to build a multi-architecture container + image, and push it to Docker Hub. You'll use Ubuntu or SUSE on the VM + and validate that the agent is online. By the end, you'll have a published + image and a running Flask service to confirm the build. + faqs: + - question: Which Google Cloud instance type and OS should I use for the VM? + answer: >- + Use a Google Axion C4A Arm VM, specifically `c4a-standard-4` with 4 vCPUs and 16 + GB memory. You can select either Ubuntu or SUSE Linux Enterprise Server as the OS. + - question: Where do I create the Buildkite agent token, and when do I use it? + answer: >- + Create an agent token in your Buildkite organization after signing in (GitHub sign-in is + supported). You use this token during the agent installation and configuration on the C4A + VM. + - question: How do I confirm the Buildkite agent is connected and assigned to the right queue? + answer: >- + After configuring the agent and queue, check the Agents page in Buildkite; the agent should + appear online with the expected queue. If it doesn't, check the agent configuration and + queue name, then repeat the verification step. + - question: What files should my GitHub repository contain for the example application? + answer: >- + Add a Dockerfile and a Python file named `app.py`. The provided Dockerfile uses `python:3.12-slim`, + installs Flask, exposes port 5000, and runs the app. + - question: What result should I expect after the pipeline runs successfully? + answer: >- + A multi-architecture Docker image for Arm and x86 is built with Docker Buildx and pushed + to Docker Hub. You then start the containerized Flask application and verify that it runs + as the final validation step. +# END generated_summary_faq + author: Jason Andrews -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/cassandra-on-gcp/_index.md b/content/learning-paths/servers-and-cloud-computing/cassandra-on-gcp/_index.md index 5d358c7fb1..2e9e883254 100644 --- a/content/learning-paths/servers-and-cloud-computing/cassandra-on-gcp/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cassandra-on-gcp/_index.md @@ -16,9 +16,55 @@ prerequisites: - A [Google Cloud Platform (GCP)](https://cloud.google.com/free) account with billing enabled - Familiarity with Cassandra architecture, replication, and [Cassandra partitioning and event-driven I/O](https://cassandra.apache.org/doc/stable/cassandra/architecture/) +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:40:18Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: b8268d4df3b62aeb9943b750b436a936134d47745fa71db6cc08db8c84eb37be + summary_generated_at: '2026-06-30T21:40:18Z' + summary_source_hash: b8268d4df3b62aeb9943b750b436a936134d47745fa71db6cc08db8c84eb37be + faq_generated_at: '2026-06-30T21:40:18Z' + faq_source_hash: b8268d4df3b62aeb9943b750b436a936134d47745fa71db6cc08db8c84eb37be + summary: >- + You'll deploy Apache Cassandra on Arm-based Google + Cloud Axion C4A virtual machines and validate a working baseline before running sample workload + tests. First, you'll create a `c4a-standard-4` instance in the Google Cloud console and install Cassandra + on Ubuntu or SUSE. Then, you'll start Cassandra as a background + service, with logs tailed to confirm “Startup complete,” followed by nodetool status to verify + the node state. By the end, you'll benchmark using the built-in `cassandra-stress` utility + to exercise write, read, and mixed operations on Arm to + confirm Cassandra is operating correctly. + faqs: + - question: Which Google Cloud machine type should I choose for this setup? + answer: >- + Select the `c4a-standard-4` machine type (4 vCPUs, 16 GB memory) when creating the VM. This + aligns with the example in the provisioning step. + - question: How do I start Cassandra and confirm it is ready? + answer: >- + Start Cassandra with `cassandra -R` to run it in the background. Tail `~/cassandra/logs/system.log` + and wait for the “Startup complete” message, then use `nodetool status` to check the node + state. + - question: What should I check in nodetool status before continuing? + answer: >- + Verify that `nodetool status` returns the node’s status and cluster information. Use this + as a quick check that the service is responding before running any benchmarks. + - question: Where is `cassandra-stress` located and how can I verify it’s installed? + answer: >- + `cassandra-stress` is in the tools/bin directory of your Cassandra installation. List the + directory and confirm it appears, for example with `ls ~/cassandra/tools/bin | grep cassandra-stress`. + - question: Which Java version does the installation use in this guide? + answer: >- + Cassandra requires a Java runtime. The example uses Java 17. +# END generated_summary_faq + author: Pareena Verma -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/cca-container/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-container/_index.md index d093d3e3bf..d41b31b17e 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-container/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-container/_index.md @@ -16,11 +16,57 @@ learning_objectives: prerequisites: - An AArch64 or x86_64 computer running Linux or macOS. You can use cloud instances, refer to the list of [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/). +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:40:49Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: 3947ebbac742399e70001e41ac5face92819bed0deb55aba3e2414f98432023e + summary_generated_at: '2026-06-30T21:40:49Z' + summary_source_hash: 3947ebbac742399e70001e41ac5face92819bed0deb55aba3e2414f98432023e + faq_generated_at: '2026-06-30T21:40:49Z' + faq_source_hash: 3947ebbac742399e70001e41ac5face92819bed0deb55aba3e2414f98432023e + summary: >- + You'll run the Arm Confidential Compute Architecture (CCA) reference + software stack on an Armv‑A AEM Base FVP with Realm Management Extension (RME) support using + a pre-built Docker image. First, you'll boot a guest Linux virtual machine as a Realm, then inject + and run a simple application inside that Realm so the program inherits the Realm’s confidential + protections. You'll also obtain a CCA attestation token from the Realm guest and learn about Memory Encryption Contexts (MEC) and how the CCA stack can + run with multiple encryption contexts in the Realm Physical Address Space. By the end, you'll + see the Realm guest launch, run the injected app, and produce an attestation token. + faqs: + - question: Which Docker image does this path use, and how do I confirm it downloaded? + answer: >- + Pull `armswdev/cca-learning-path:cca-simulation-v3`. Run `docker image list` and check that + this repository and tag appear in the output. + - question: What result should I expect when the Realm guest virtual machine starts? + answer: >- + The guest virtual machine (VM) should boot as a Realm and run guest Linux. Continue when the + VM is up and ready for the application injection step. + - question: How do I place the sample application inside the Realm? + answer: >- + Inject the application into the guest filesystem as shown in the steps. Verify inside the + guest that the file exists and is executable, then run it to confirm expected output. + - question: Where do I retrieve the CCA attestation token in this workflow? + answer: >- + Request the token from inside the virtual guest running in the Realm. Follow the path step + to capture the token and confirm that a token is returned. + - question: What changes when running with Memory Encryption Contexts (MEC)? + answer: >- + Use the MEC section to run the CCA stack with multiple encryption contexts in the Realm + Physical Address Space, identified by a MECID. The example follows the same Realm guest + and application flow while enabling MEC. +# END generated_summary_faq + author: - Pareena Verma - Arnaud de Grandmaison -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/cca-device-attach/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-device-attach/_index.md index 9958808c73..995ca34d48 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-device-attach/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-device-attach/_index.md @@ -19,9 +19,61 @@ prerequisites: - Completion of the [Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](/learning-paths/servers-and-cloud-computing/cca-container/) Learning Path - Completion of the [Run an end-to-end Attestation Flow](/learning-paths/servers-and-cloud-computing/cca-essentials/) Learning Path +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:41:31Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: 2fca6f2863b4909021d529f868fde7c6abe5393a0d7c229477645b261436e705 + summary_generated_at: '2026-06-30T21:41:31Z' + summary_source_hash: 2fca6f2863b4909021d529f868fde7c6abe5393a0d7c229477645b261436e705 + faq_generated_at: '2026-06-30T21:41:31Z' + faq_source_hash: 2fca6f2863b4909021d529f868fde7c6abe5393a0d7c229477645b261436e705 + summary: >- + You'll examine how Arm CCA Realms attach to I/O devices through two models: paravirtualized + VirtIO and secure physical device attach. First, you'll learn about Realm isolation with RME, + how VirtIO enables mediated device access, and why SWIOTLB bounce buffers are used + when devices can't DMA directly to Realm memory. You'll also explore how PCIe‑TDISP and PCIe‑IDE + provide secure device attach with attestation. Then, you'll run a pre-built Key Broker + demo inside a Realm and use kernel tracing to observe SWIOTLB activity during VirtIO network + I/O. By the end, you'll recognize when data paths rely on bounce buffers and how this relates + to the chosen device attach method. + faqs: + - question: How do I know that bounce buffers are being used in the Realm? + answer: >- + Use kernel tracing during the exercise to observe activity indicating SWIOTLB usage while + the Key Broker demo generates network I/O through VirtIO. Seeing trace output associated + with SWIOTLB during traffic confirms that data is bouncing through DMA-capable buffers. + - question: What should I expect after starting the Key Broker container image? + answer: >- + The container runs a pre-built Key Broker demo used in the exercise. After it starts, list + network interfaces to confirm connectivity before proceeding to kernel tracing. + - question: When is VirtIO the right choice versus secure physical device attach? + answer: >- + VirtIO is the first level of device attach, mediated by the hypervisor with paravirtualized + drivers, and is sufficient for many Realm I/O needs. Secure physical device attach using + PCIe‑TDISP and PCIe‑IDE applies when hardware-backed isolation and attestation for the device + are required. + - question: Why do Realms rely on SWIOTLB bounce buffers for I/O? + answer: >- + Bounce buffers are used when a device cannot DMA to the original buffer, including when + memory is not accessible to the device or does not meet alignment or contiguity constraints. + In Realms, SWIOTLB enables data transfer between Realm-protected memory and devices during + VirtIO I/O. + - question: Will I learn to perform attestation of a physically attached device? + answer: >- + You'll learn how PCIe‑TDISP and PCIe‑IDE support secure physical device attach and + attestation. The hands-on exercise focuses on VirtIO and observing SWIOTLB behavior, not + on performing a physical device attestation workflow. +# END generated_summary_faq + author: Arnaud de Grandmaison -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md index 997aa805b9..ad9b16806d 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-essentials/_index.md @@ -16,12 +16,62 @@ prerequisites: - Completion of [Get Started with CCA Attestation and Veraison](/learning-paths/servers-and-cloud-computing/cca-veraison/) Learning Path. - Completion of the [Run an application in a Realm using the Arm Confidential Computing Architecture (CCA)](/learning-paths/servers-and-cloud-computing/cca-container/) Learning Path. +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:42:00Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: ba896cb418c6ae4f96029081ac9ef1f9193e8983425ad7a316c184b5b6017fbf + summary_generated_at: '2026-06-30T21:42:00Z' + summary_source_hash: ba896cb418c6ae4f96029081ac9ef1f9193e8983425ad7a316c184b5b6017fbf + faq_generated_at: '2026-06-30T21:42:00Z' + faq_source_hash: ba896cb418c6ae4f96029081ac9ef1f9193e8983425ad7a316c184b5b6017fbf + summary: >- + You'll deploy a sample workload in a Linux realm on + an Armv9-A AEM Base Fixed Virtual Platform (FVP) with Realm Management Extension (RME) support + and connect it to attestation services to control access to secrets. First, you'll start a minimal + Key Broker Server (KBS) from the Veraison project in a container, then integrate it with the + realm so that confidential data is released only after successful attestation. You'll focus + on the flow of evidence, verification, and key release to recognize a complete + end-to-end run when service logs report a successful attestation result and the workload in + the realm receives its key. + faqs: + - question: Which components need to be running to exercise the end-to-end flow? + answer: >- + You need the RME-enabled Armv9-A AEM Base FVP hosting a Linux realm, the attestation services, + and the Veraison Key Broker Server (KBS) container. Run these in the order described so + that attestation can evaluate the realm before secrets are requested. + - question: How do I know the Key Broker Server is ready? + answer: >- + After starting the provided container image, confirm the container is running and check + its logs for a startup or listening message. Proceed only when the KBS indicates it is ready + to handle requests. + - question: What result should I expect when attestation succeeds? + answer: >- + The attestation services accept the realm’s evidence, and the KBS authorizes release of + a key or secret. You should see logs showing a positive attestation outcome and the workload + receiving the expected data. + - question: When should the confidential data be released to the realm? + answer: >- + Only after the attestation step verifies that the Linux realm provides the required level + of confidential isolation. The example gates key release on that successful verification. + - question: What should I check if attestation fails or no key is returned? + answer: >- + Verify the Linux realm is running on the RME-enabled FVP and that the attestation services + and KBS are up and reachable. Inspect their logs for configuration or connectivity errors, + then restart the flow after addressing the issue. +# END generated_summary_faq + author: - Arnaud de Grandmaison - Paul Howard - Pareena Verma -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/cca-kata/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-kata/_index.md index cd22f344ac..d2f2e687ab 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-kata/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-kata/_index.md @@ -15,10 +15,58 @@ prerequisites: - An AArch64 or x86_64 computer running Linux or macOS. Cloud-based instances can also be used; see the [Arm cloud service providers](/learning-paths/servers-and-cloud-computing/csp/) - Completion of the [Run an end-to-end Attestation with Arm CCA and Trustee](/learning-paths/servers-and-cloud-computing/cca-trustee) Learning Path +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:42:36Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: 649957b07b2bde05bc11047bd12bfc4f697c1a55eef1c3a25b5fafc95cda893d + summary_generated_at: '2026-06-30T21:42:36Z' + summary_source_hash: 649957b07b2bde05bc11047bd12bfc4f697c1a55eef1c3a25b5fafc95cda893d + faq_generated_at: '2026-06-30T21:42:36Z' + faq_source_hash: 649957b07b2bde05bc11047bd12bfc4f697c1a55eef1c3a25b5fafc95cda893d + summary: >- + You'll deploy a confidential container from an encrypted + image inside an Arm CCA Realm on an Armv9-A AEM Base Fixed Virtual Platform (FVP) with Realm Management Extension (RME) support. + First, you'll learn about the Confidential Containers design, understand which components run inside the + Trusted Execution Environment, and see how Trustee services use Arm CCA + attestation to authorize decryption. Then, you'll start the Trustee services and a local Docker + registry, publish an encrypted image, and launch the container on the FVP. By the end, you'll confirm attestation, key release, and that the workload runs in a Realm only + after authorization. + faqs: + - question: How do I know the Trustee services are ready before pushing the image? + answer: >- + Confirm that the AS, KBS, and RVPS processes have started and are listening. Check their + startup logs for ready or healthy messages before continuing. + - question: Which registry should I use when publishing the encrypted image? + answer: >- + Use the local Docker registry started as part of this Learning Path. Tag the encrypted image + for that registry and push, and proceed only after the push completes without errors. + - question: What result should I expect when launching the confidential container on the FVP? + answer: >- + The runtime pulls the encrypted image from the local registry, performs Arm CCA attestation + via Trustee, obtains decryption keys, and starts the workload inside an Arm CCA Realm. Expect + logs indicating successful attestation or authorization and that the container is running. + - question: How can I verify the container is actually running inside an Arm CCA Realm? + answer: >- + Follow the verification step to check Realm-specific output from the launch. Validation + relies on Trustee accepting CCA attestation evidence; without acceptance, the image remains + locked and the workload does not start. + - question: What should I check if the encrypted image fails to pull or decrypt during launch? + answer: >- + Verify the local registry is running and reachable and that the image was pushed with the + expected tag. Confirm AS, KBS, and RVPS are up and that attestation evidence is available + so the KBS can release keys after authorization. +# END generated_summary_faq + author: - Anton Antonov -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/cca-trustee/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-trustee/_index.md index 68cc42600d..bb564989b4 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-trustee/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-trustee/_index.md @@ -16,10 +16,56 @@ prerequisites: - Completion of the [Get started with CCA attestation and Veraison](/learning-paths/servers-and-cloud-computing/cca-veraison/) Learning Path - Completion of the [Run an end-to-end attestation flow with Arm CCA](/learning-paths/servers-and-cloud-computing/cca-essentials/) Learning Path +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:43:12Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: 7046b0fb5519afea3a779675c948ef0b423678c1feff23be2bd4ba37c19698e8 + summary_generated_at: '2026-06-30T21:43:12Z' + summary_source_hash: 7046b0fb5519afea3a779675c948ef0b423678c1feff23be2bd4ba37c19698e8 + faq_generated_at: '2026-06-30T21:43:12Z' + faq_source_hash: 7046b0fb5519afea3a779675c948ef0b423678c1feff23be2bd4ba37c19698e8 + summary: >- + You'll complete an end-to-end confidential computing attestation + flow on an Arm Fixed Virtual Platform using Arm Confidential Compute Architecture and Trustee + services. First, you'll start the Trustee components, launch a Linux realm on an + Armv9-A FVP with Realm Management Extension (RME), and generate attestation evidence from the realm. After intentionally + denying the first secret request to see how policy-based gating works, you'll endorse the + realm initial measurement (RIM), repeat attestation, and retrieve the secret after the environment + proves its isolation properties. By the end, you'll exercise and validate the complete path from evidence generation to + policy-controlled secret release. + faqs: + - question: What result should I expect from the first secret request? + answer: >- + The initial request is expected to fail. The attestation policy blocks secret release until + the realm initial measurement (RIM) is endorsed. + - question: How do I know the Trustee services are running correctly before launching the realm? + answer: >- + Check the Docker container status and logs for the Trustee services. They should + start without errors and be ready to accept requests. + - question: When should I endorse the RIM, and how do I confirm it worked? + answer: >- + Endorse the RIM after the first secret request is denied. After endorsement, re-run attestation + and expect the secret request to succeed. + - question: How can I verify that the realm generated attestation evidence? + answer: >- + The realm run produces evidence that the Attestation Service (AS) processes. Check the output + and logs for evidence generation and a corresponding response from the AS. + - question: How do I know the FVP realm is ready before requesting a secret? + answer: >- + The Linux realm should complete boot on the FVP and be able to produce attestation evidence. + If evidence generation fails, resolve that before proceeding to secret requests. +# END generated_summary_faq + author: - Anton Antonov -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/cca-veraison-aws/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-veraison-aws/_index.md index 09d50edfb2..c0e1fc5cb1 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-veraison-aws/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-veraison-aws/_index.md @@ -14,9 +14,58 @@ prerequisites: - An [AWS account](/learning-paths/servers-and-cloud-computing/csp/aws/) with access to AWS services. - An x86 computer running Ubuntu or Arch Linux, authorized for AWS access. If you're using another build environment, you'll need to configure the toolchains for cross-compilation. +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:43:42Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: 55b8032ceaf735d53b1157102a3a1da5aa5cb686e9ec51cf4896ded66d9bf263 + summary_generated_at: '2026-06-30T21:43:42Z' + summary_source_hash: 55b8032ceaf735d53b1157102a3a1da5aa5cb686e9ec51cf4896ded66d9bf263 + faq_generated_at: '2026-06-30T21:43:42Z' + faq_source_hash: 55b8032ceaf735d53b1157102a3a1da5aa5cb686e9ec51cf4896ded66d9bf263 + summary: >- + You'll deploy Veraison on AWS to serve as the Verifier + in the RATS (RFC9334) model for Arm CCA attestation. After preparing an AWS account and authenticating, + you'll create a Route53 domain and an HTTPS certificate so the Veraison REST APIs can be + published on the internet. You'll deploy from the Veraison GitHub repository and + use a bootstrap process to clone sources and set up the build environment. With the services running, you'll provision CCA + platform endorsements using the Linaro endorsement tool so Veraison can verify CCA attestation + tokens. + faqs: + - question: What should I have in place on AWS before starting the deployment? + answer: >- + Use an active AWS account with administrator-level privileges and install the AWS CLI. Set + up authentication in your local environment following the AWS documentation before proceeding. + - question: Why do I need a Route53 domain and a certificate for this deployment? + answer: >- + The Veraison services are published on the internet and accessed over HTTPS using RESTful + APIs. A Route53-managed domain and a valid certificate allow clients to reliably reach the + services via DNS and establish secure connections. + - question: How do I begin the automated Veraison deployment and how long will it take? + answer: >- + Start with the Bootstrap process from the Veraison GitHub repository to clone the source + and set up the build environment, which also installs required dependencies. The AWS resource + creation typically takes 30 to 60 minutes. + - question: Where do I get the tool to add CCA platform endorsements? + answer: >- + Clone the Linaro endorsement tool from the Linaro Git server using: `git clone https://git.codelinaro.org/linaro/dcap/cca-demos/poc-endorser`. + Configure the tool for AWS as described in the steps to provide the CCA platform endorsements + to Veraison. + - question: What indicates the verifier is ready to handle CCA tokens after deployment? + answer: >- + After the Veraison services are running and CCA platform endorsements have been provisioned, + the deployment is set up for CCA attestation verification. The services are exposed via + HTTPS on your configured domain. +# END generated_summary_faq + author: Paul Howard -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/cca-veraison/_index.md b/content/learning-paths/servers-and-cloud-computing/cca-veraison/_index.md index a8d92ef36c..e050d62048 100644 --- a/content/learning-paths/servers-and-cloud-computing/cca-veraison/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cca-veraison/_index.md @@ -1,5 +1,5 @@ --- -title: Get Started with CCA Attestation and Veraison +title: Get started with CCA Attestation and Veraison description: Learn how to inspect and verify Arm CCA attestation tokens using command-line tools and the open-source Veraison attestation verification service. minutes_to_complete: 30 @@ -16,9 +16,55 @@ learning_objectives: prerequisites: - An Arm-based or x86 computer running Ubuntu. You can use a server instance from a cloud service provider of your choice. +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:44:15Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: 9e6dee3aef79c1c65cc1a1f4fe3528b9c5542d8046f0b059ef703079ef964d77 + summary_generated_at: '2026-06-30T21:44:15Z' + summary_source_hash: 9e6dee3aef79c1c65cc1a1f4fe3528b9c5542d8046f0b059ef703079ef964d77 + faq_generated_at: '2026-06-30T21:44:15Z' + faq_source_hash: 9e6dee3aef79c1c65cc1a1f4fe3528b9c5542d8046f0b059ef703079ef964d77 + summary: >- + You'll learn about CCA attestation by connecting the concepts of confidential computing + and Arm’s Realm Management Extension to practical token handling. First, you'll start with an overview + of attestation and Veraison, then obtain an example CCA attestation token + and set up the required tools by installing Go. You'll inspect the token’s structure using + command-line workflows, then submit it to a Linaro-hosted verification service implemented + with Veraison components. By the end, you'll recognize a successful verification response and be able to relate it back to the token + contents that you inspected. + faqs: + - question: Should I remove an existing Go installation before setting up the tools? + answer: >- + Yes. The steps direct you to remove any existing Go installation before downloading and + extracting the specified Go release and updating your `PATH`. + - question: What can I verify locally before using the online verification service? + answer: >- + You can inspect the example CCA attestation token with command-line workflows to review + its data and format. This helps you understand what the service will evaluate. + - question: How do I know the token I’m using is supported by the verifier? + answer: >- + The verifier targets pre-silicon CCA platforms, such as emulated Arm platforms like FVP. + The example token provided in this exercise is suitable for this service. + - question: What result should I expect after submitting a token to the verification service? + answer: >- + You should receive a verification response from the Veraison-based service indicating the + evaluation outcome. Use that result to confirm the token’s validity for the targeted pre-silicon + environment. + - question: Do I need access to CCA hardware to follow this Learning Path? + answer: >- + No. You'll use an example token and a publicly available verifier for emulated pre-silicon + CCA platforms hosted by Linaro. +# END generated_summary_faq + author: Paul Howard -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/circleci-gcp/_index.md b/content/learning-paths/servers-and-cloud-computing/circleci-gcp/_index.md index 3e98b6690f..0263dcc716 100644 --- a/content/learning-paths/servers-and-cloud-computing/circleci-gcp/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/circleci-gcp/_index.md @@ -22,9 +22,58 @@ prerequisites: [resource classes](https://circleci.com/docs/guides/execution-managed/resource-class-overview/), and [runners](https://circleci.com/docs/guides/execution-runner/runner-overview/) +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:44:47Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: ec9cdca7aa9a5670f54ea3646f965149460d8e66d9d5d904e1b6dcf09867df39 + summary_generated_at: '2026-06-30T21:44:47Z' + summary_source_hash: ec9cdca7aa9a5670f54ea3646f965149460d8e66d9d5d904e1b6dcf09867df39 + faq_generated_at: '2026-06-30T21:44:47Z' + faq_source_hash: ec9cdca7aa9a5670f54ea3646f965149460d8e66d9d5d904e1b6dcf09867df39 + summary: >- + You'll provision a SUSE Linux Google Cloud C4A virtual machine (VM) powered by Google Axion, + install the CircleCI CLI, create a custom resource class, and deploy the CircleCI Machine + Runner so CI/CD jobs execute natively on Arm. After configuring a self-hosted runner linked + to a CircleCI namespace, you'll author and dispatch a workflow that targets the resource class and runs a + small Node.js demo app on the Arm VM. You'll then verify its execution in the CircleCI dashboard + and on the VM. + faqs: + - question: How do I know I created the correct C4A Arm VM in Google Cloud? + answer: >- + During creation, select the `c4a-standard-4` machine type in the Google Cloud Console. After + launch, open the VM details in Compute Engine and verify the machine type shows `c4a-standard-4`. + - question: What should I verify after installing the CircleCI CLI on SUSE? + answer: >- + The CLI should be available to validate configuration files, run jobs locally, and manage + runners. If it can't be installed or used, recheck that the required repositories were + added to the SUSE environment as shown in the steps. + - question: Which namespace should I use when creating the CircleCI resource class? + answer: >- + Use the CircleCI organization (namespace) where your project workflows run. The resource + class links your self-hosted runner to that namespace so only authorized jobs can target + the VM. + - question: How can I confirm the machine runner is registered and ready to accept jobs? + answer: >- + Check the CircleCI web dashboard for the resource class and runner status. On the VM, the + runner setup completes with a connection to CircleCI and then waits for jobs that reference + its resource class. + - question: How do I target the self-hosted Arm runner from my workflow, and what result should + I expect? + answer: >- + Configure the job to use the custom resource class created for the Arm runner. When triggered, + the job runs on the SUSE arm64 VM and the CircleCI UI shows the job associated with that + resource class. +# END generated_summary_faq + author: Pareena Verma -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/circleci-on-aws/_index.md b/content/learning-paths/servers-and-cloud-computing/circleci-on-aws/_index.md index 750ffb038c..4dccf7ee3c 100644 --- a/content/learning-paths/servers-and-cloud-computing/circleci-on-aws/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/circleci-on-aws/_index.md @@ -4,10 +4,10 @@ description: Learn how to install and configure CircleCI self-hosted machine run minutes_to_complete: 30 -who_is_this_for: This is an introductory topic for developers and DevOps engineers who want to set up and run CircleCI Arm native workflows on Linux Arm64 virtual machines. You'll use AWS EC2 Graviton instances (Neoverse N1) and self-hosted runners. +who_is_this_for: This is an introductory topic for developers and DevOps engineers who want to set up and run CircleCI Arm native workflows on Linux Arm64 virtual machines. You'll use Amazon EC2 instances powered by AWS Graviton (Neoverse N1) and self-hosted runners. learning_objectives: - - Create an AWS EC2 Graviton Arm64 virtual machine + - Create an Amazon EC2 Arm64 virtual machine - Install and configure CircleCI self-hosted machine runners on Arm64 - Verify the runner by running a simple workflow and test computation @@ -16,9 +16,57 @@ prerequisites: - A CircleCI account - Basic understanding of CircleCI workflows, jobs and resource classes +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:45:26Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: e04982fd668765fa2ab25f943f020b8d2b4a5e9b5ff3a51b7431cc4d93730180 + summary_generated_at: '2026-06-30T21:45:26Z' + summary_source_hash: e04982fd668765fa2ab25f943f020b8d2b4a5e9b5ff3a51b7431cc4d93730180 + faq_generated_at: '2026-06-30T21:45:26Z' + faq_source_hash: e04982fd668765fa2ab25f943f020b8d2b4a5e9b5ff3a51b7431cc4d93730180 + summary: >- + You'll deploy CircleCI Arm-native workflows on Amazon + EC2 instances powered by AWS Graviton. Using the AWS Management Console, you'll provision an Arm-based instance (for + example, `m6g.large`) on Linux and install the CircleCI CLI to work with configurations and + pipelines from the terminal. In the CircleCI dashboard, you'll create a resource class to link + a self-hosted machine runner to the correct namespace. Then, you'll install the CircleCI + machine runner on the Arm64 instance using the CircleCI package repository for Debian/Ubuntu + systems. By the end, you'll execute a workflow and test computation to verify that jobs + run on the self-hosted Graviton runner as configured. + faqs: + - question: Which EC2 instance and AMI should I select to follow the steps? + answer: >- + Use an Amazon EC2 instance powered by AWS Graviton, such as `m6g.large`, and choose a Linux AMI such as Ubuntu + in the AWS Management Console. You'll follow a console-based instance launch workflow. + - question: What should I install before setting up the CircleCI CLI? + answer: >- + Install curl, tar, gzip, coreutils, gpg, and git using your package manager. These tools + enable downloading, verifying, and extracting the CLI. + - question: What do I need before creating a resource class for the self-hosted runner? + answer: >- + Access the CircleCI dashboard and ensure an organization/namespace is available. The resource + class links your runner to that namespace so jobs can target it. + - question: How do I confirm the machine runner is installed and connected? + answer: >- + After adding the CircleCI package repository and installing the runner, the agent registers + to your resource class. Running the sample workflow should start on the EC2 instance and + complete the test computation. + - question: What should I check if a job does not run on the self-hosted runner? + answer: >- + Verify the job targets the resource class you created, the EC2 instance is running, and + the runner process is installed on that instance. Then re-run the workflow from the CircleCI + dashboard. +# END generated_summary_faq + author: Annie Tallund -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/clair/_index.md b/content/learning-paths/servers-and-cloud-computing/clair/_index.md index 28ffd36c29..50a9ca3839 100644 --- a/content/learning-paths/servers-and-cloud-computing/clair/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/clair/_index.md @@ -14,9 +14,55 @@ learning_objectives: prerequisites: - An [Arm based instance](/learning-paths/servers-and-cloud-computing/csp/) from a cloud service provider or an Arm server with recent versions of Docker and Go installed. +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:46:01Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: e742eb44fa108bfcc4ee5a241414e6aa05e1fc0e1cceb589fb78a080f59b0d38 + summary_generated_at: '2026-06-30T21:46:01Z' + summary_source_hash: e742eb44fa108bfcc4ee5a241414e6aa05e1fc0e1cceb589fb78a080f59b0d38 + faq_generated_at: '2026-06-30T21:46:01Z' + faq_source_hash: e742eb44fa108bfcc4ee5a241414e6aa05e1fc0e1cceb589fb78a080f59b0d38 + summary: >- + You'll install and run Clair on Arm-based Linux servers using both + combined and distributed deployment models. First, you'll set up the combined deployment to run + all services in a single process, then explore the distributed option where the indexer, matcher, + and notifier operate as separate services. With Clair running, you'll submit a container image manifest using `clairctl` to perform static analysis and generate a vulnerability report. + You'll learn about timing considerations — allowing initial vulnerability data to populate + the PostgreSQL database — so reports reflect current findings. By the end, you'll launch Clair, + select a deployment model, and produce a report for a chosen image. + faqs: + - question: Which deployment model should I start with? + answer: >- + The combined deployment runs all Clair services in a single OS process and is the easiest + to configure. The distributed deployment runs the indexer, matcher, and notifier as separate + services. + - question: How do I know Clair is ready before submitting a manifest? + answer: >- + Wait 5–10 minutes after starting Clair for vulnerabilities to populate in the PostgreSQL + database. Submitting too soon can return a clean report even when issues exist. If that + happens, wait and resubmit. + - question: What do I submit to Clair to scan an image? + answer: >- + Submit the image’s manifest to your running Clair deployment using clairctl. The CLI sends + the request and returns a vulnerability report when analysis completes. + - question: In a distributed deployment, which services run separately? + answer: >- + The indexer, matcher, and notifier run as separate services in a distributed setup. The + indexer retrieves image layers, scans them, and generates an intermediate IndexReport. + - question: Does Clair run the container image during analysis? + answer: >- + No. Clair performs static analysis of container images without running them. +# END generated_summary_faq + author: Jason Andrews -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/clickhouse-gcp/_index.md b/content/learning-paths/servers-and-cloud-computing/clickhouse-gcp/_index.md index 76b947e133..266dd7eaf4 100644 --- a/content/learning-paths/servers-and-cloud-computing/clickhouse-gcp/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/clickhouse-gcp/_index.md @@ -21,9 +21,53 @@ prerequisites: - Basic familiarity with [ClickHouse](https://clickhouse.com/) - Basic understanding of databases and SQL +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:46:38Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: e77cd1373236f39f360afe6844d642fde290960ccdad26544ff1e3342f2a980c + summary_generated_at: '2026-06-30T21:46:38Z' + summary_source_hash: e77cd1373236f39f360afe6844d642fde290960ccdad26544ff1e3342f2a980c + faq_generated_at: '2026-06-30T21:46:38Z' + faq_source_hash: e77cd1373236f39f360afe6844d642fde290960ccdad26544ff1e3342f2a980c + summary: >- + You'll deploy ClickHouse on an Arm-based Google Cloud C4A virtual machine and assemble a streaming analytics pipeline. After exploring C4A (Neoverse-V2) instances, you'll provision a `c4a-standard-4` SUSE Linux VM, create + a firewall rule to open TCP port 8123, and install ClickHouse alongside the Google Cloud CLI. + Then, you'll set up Pub/Sub and required IAM so Apache Beam on Dataflow can stream events + into ClickHouse. By the end, you'll validate end-to-end ingestion from Pub/Sub to ClickHouse and run + baseline and analytical queries, capturing latency metrics (including p95) to evaluate ClickHouse + behavior on Axion processors. + faqs: + - question: Which machine type should I choose for the VM in this path? + answer: >- + Select the `c4a-standard-4` machine type (4 vCPUs, 16 GB) in the Google Cloud console when + creating the instance. This matches the configuration used in the steps. + - question: Which firewall port needs to be opened for ClickHouse access? + answer: >- + Open inbound TCP port 8123 by creating a firewall rule in your VPC. This exposes the ClickHouse + endpoint required by the path. + - question: How do I verify Pub/Sub is ready before launching the pipeline? + answer: >- + Confirm that the logs-topic exists under **Pub/Sub → Topics** and keep encryption and retention + at their defaults. Complete the IAM setup so Dataflow and the VM can access Pub/Sub. + - question: Where should I install and use the Google Cloud CLI (`gcloud`) during this workflow? + answer: >- + Install the Google Cloud CLI on the VM. Use it to authenticate + to GCP, publish Pub/Sub messages, and submit Dataflow jobs. + - question: What results should I record when validating and benchmarking ClickHouse? + answer: >- + Verify that events published to Pub/Sub arrive in ClickHouse and then run baseline and analytical + queries. Capture query latency metrics, including p95. +# END generated_summary_faq + author: Pareena Verma -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/clickhouse/_index.md b/content/learning-paths/servers-and-cloud-computing/clickhouse/_index.md index 747db8f678..aa9414fbe6 100644 --- a/content/learning-paths/servers-and-cloud-computing/clickhouse/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/clickhouse/_index.md @@ -13,9 +13,55 @@ learning_objectives: prerequisites: - An [Arm based instance](/learning-paths/servers-and-cloud-computing/csp/) from a cloud service provider or an on-premise Arm server. +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:47:22Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: 0d1390198cf2f0e87f509c5269fc2405cffcb2e57311024150d47e60a3273178 + summary_generated_at: '2026-06-30T21:47:22Z' + summary_source_hash: 0d1390198cf2f0e87f509c5269fc2405cffcb2e57311024150d47e60a3273178 + faq_generated_at: '2026-06-30T21:47:22Z' + faq_source_hash: 0d1390198cf2f0e87f509c5269fc2405cffcb2e57311024150d47e60a3273178 + summary: >- + You'll install ClickHouse on an Arm-based cloud instance, load the + ClickBench web-analytics dataset, and run ClickBench to measure query latency. You'll execute + the benchmark on an Arm server, observe per‑query timings, and repeat runs across candidate + instance sizes to compare results. By collecting consistent measurements + and interpreting the output, you can make instance sizing decisions for analytical workloads + on Arm. + faqs: + - question: What should I verify on the instance before starting the benchmark? + answer: >- + Use an Arm server or Arm-based cloud instance with a recent Ubuntu for Arm and enough storage + for the web-analytics dataset. Check available disk space before starting the data load. + - question: Which dataset is used and how much storage should I plan for? + answer: >- + The benchmark uses the ClickBench web-analytics dataset. The exact size is not listed here, + so allocate sufficient storage and monitor free space during import. + - question: How do I know ClickHouse is ready to run ClickBench? + answer: >- + Complete the installation, start ClickHouse, and follow the steps to confirm it accepts + connections. Proceed when the setup reports the dataset is loaded and the required tables + are available. + - question: What result should I expect after running ClickBench? + answer: >- + ClickBench reports per‑query latency measurements and a summary of timings for the workload. + Use these outputs as the basis for comparing configurations. + - question: How should I compare different instance configurations? + answer: >- + Run the same ClickBench workload on each Arm-based instance with the same ClickHouse settings + and dataset. Compare the resulting latencies to choose a configuration that fits your workload + needs. +# END generated_summary_faq + author: Pareena Verma -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/content/learning-paths/servers-and-cloud-computing/cobalt/_index.md b/content/learning-paths/servers-and-cloud-computing/cobalt/_index.md index 72bc9c0350..084d4fe88c 100644 --- a/content/learning-paths/servers-and-cloud-computing/cobalt/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/cobalt/_index.md @@ -16,9 +16,55 @@ prerequisites: - A Microsoft Azure subscription with permissions to create virtual machines and networking resources - Basic familiarity with SSH +# START generated_summary_faq +generated_summary_faq: + template_version: summary-faq-v3 + generated_at: '2026-06-30T21:48:05Z' + generator: ai + ai_assisted: true + ai_review_required: true + model: gpt-5 + prompt_template: summary-faq-v3 + source_hash: e4eb84292a669a8d73bff4b63d2fe3f70382dd873d023fc8ff24db5ad6178ab8 + summary_generated_at: '2026-06-30T21:48:05Z' + summary_source_hash: e4eb84292a669a8d73bff4b63d2fe3f70382dd873d023fc8ff24db5ad6178ab8 + faq_generated_at: '2026-06-30T21:48:05Z' + faq_source_hash: e4eb84292a669a8d73bff4b63d2fe3f70382dd873d023fc8ff24db5ad6178ab8 + summary: >- + You'll deploy an Arm-based virtual machine (VM) in Microsoft + Azure using the Azure portal, select an appropriate VM series, and prepare it for remote access + and basic testing. First, you'll create the VM, then configure the associated Network Security + Group to allow inbound SSH (port 22) and an application test port (8080). By the end, you'll connect over SSH using the VM’s public IP address and validate external connectivity over the configured source IP range + by running a service on the chosen port. + faqs: + - question: How do I choose between Dpsv6/Dplsv6 and Epsv6 when creating the VM? + answer: >- + Dpsv6 and Dplsv6 are general-purpose series, while Epsv6 is memory-optimized. Select a series + that aligns with the memory needs of your workload. + - question: Where do I find the VM’s public IP address for SSH? + answer: >- + Open the VM resource in the Azure Portal and copy the Public IP address from the Overview + page. Use the admin username you set during creation (for example, `azureuser`) and the path + to your SSH private key. + - question: What should I check if SSH times out or is refused? + answer: >- + Verify the Network Security Group has an inbound rule allowing TCP port 22 from your client + IP. Also confirm you’re using the correct public IP address and the admin username you chose + during VM creation. + - question: Which IP range should I allow when opening port 8080 in the NSG? + answer: >- + For testing, allow traffic from your IP to limit exposure. Adjust the source IP range or + choose a different port if your workload requires broader access or a non-default port. + - question: What result should I expect when verifying port 8080 connectivity? + answer: >- + With an application or temporary HTTP server listening on port 8080, connecting to `http://[public + IP]:8080` should return a response. If it doesn’t, re-check the NSG rule and ensure the service + is running on the VM. +# END generated_summary_faq + author: Joe Stech -generate_summary_faq: true +generate_summary_faq: false rerun_summary: false rerun_faqs: false diff --git a/tools/generate_summary_faq.py b/tools/generate_summary_faq.py index 864e993583..6403bf6b20 100644 --- a/tools/generate_summary_faq.py +++ b/tools/generate_summary_faq.py @@ -65,7 +65,7 @@ LEARNING_PATH_ROOT = REPO_ROOT / "content" / "learning-paths" DEFAULT_REPORT_PATH = REPO_ROOT / "reports" / "generated-summary-faq" / "latest-run.yml" DEFAULT_PROMPT_DIR = REPO_ROOT / "tools" / "prompts" -COPILOT_INSTRUCTIONS_PATH = REPO_ROOT / ".github" / "copilot-instructions.md" +WRITING_STYLE_SKILL = REPO_ROOT / ".github" / "skills" / "writing-style-review" / "SKILL.md" LEARNING_PATH_AUTHORING_GUIDE_DIR = LEARNING_PATH_ROOT / "cross-platform" / "_example-learning-path" DEFAULT_OPENAI_BASE_URL = "https://openai-api-proxy.geo.arm.com/api/providers/openai/v1/responses/" DEFAULT_OPENAI_MODEL = "gpt-4.1-mini" @@ -74,7 +74,7 @@ DEFAULT_PROMPT_STEP_LIMIT = 8 DEFAULT_PROMPT_EXCERPT_CHARS = 900 AUTHORING_GUIDANCE_FILES = ( - (COPILOT_INSTRUCTIONS_PATH, 3200), + (WRITING_STYLE_SKILL, 3200), (LEARNING_PATH_AUTHORING_GUIDE_DIR / "overview.md", 1800), (LEARNING_PATH_AUTHORING_GUIDE_DIR / "write-2-metadata.md", 2200), (LEARNING_PATH_AUTHORING_GUIDE_DIR / "appendix-2-writing-style.md", 2600), diff --git a/tools/prompts/summary_faq_user.md b/tools/prompts/summary_faq_user.md index 0ffeb4807e..4e0155e465 100644 --- a/tools/prompts/summary_faq_user.md +++ b/tools/prompts/summary_faq_user.md @@ -15,7 +15,7 @@ Assume these rules while writing: Summary guidance: - Write the summary as an Arm Learning Path overview, not from the learner's first-person point of view. - Never use first-person wording in the summary, including "I", "we", "my", "our", or "let's". -- Use "you" sparingly in the summary. Prefer neutral phrasing such as "This Learning Path shows...", "The path guides learners through...", or "Learners configure..." unless second person is clearly more direct. +- Use direct, second person phrasing. - Say what learners build, configure, measure, deploy, debug, validate, or compare as they work through the steps. - Mention Arm technologies, tools, operating systems, and cloud platforms only when they appear in the context. - Avoid restating prerequisites, audience, objectives, or title text. The summary should add orientation around the workflow, not duplicate the surrounding page content.