Merge branch '3.0-dev' into cjnolan/update-service-dependencies

Author: cjnolan

.github/CODEOWNERS

@@ -1 +1,3 @@
 * @open-edge-platform/edge-microvisor-toolkit-maintain 
+
+/docs @open-edge-platform/edge-microvisor-toolkit-docs-write

docs/developer-guide/architecture-overview.md

@@ -11,11 +11,11 @@ Edge Microvisor Toolkit is produced and maintained in several versions, in both
 mutable images. It enables users to quickly deploy and run their workloads on Intel® platforms,
 offering quick solutions to multiple scenarios.
 
-- ISO installer with a mutable image using GRUB as the second-stage bootloader
-- ISO installer - mutable image, GRUB as the second-stage bootloader
-- RAW and VHD/X - immutable image, systemd-boot as the second-stage bootloader
+- ISO installer with a mutable image using GRUB as the second-stage bootloader.
+- ISO installer - mutable image, GRUB as the second-stage bootloader.
+- RAW and VHD/X - immutable image, systemd-boot as the second-stage bootloader.
 - RAW and VHD/X - immutable image, systemd-boot as the second-stage bootloader, with real-time
-  support
+  support.
 
 Two flavors of immutable microvisor are available, integrating the Intel® kernel and
 enabling the software and features offered by Intel® Open Edge Platform. Check out this
@@ -117,12 +117,12 @@ Limits deep idle states on Intel® CPUs, reducing wake-up latencies that can adv
 Each build of Edge Microvisor Toolkit produces several build artifacts based on
 the image configuration used. The artifacts come with associated `sha256` files.
 
-- Unique build ID
-- Manifest containing version, kernel version, size, release details and CVE manifest
-- Software BOM package manifests (included packages, dependencies, patches)
-- Signed Image in raw.gz format
-- Image in VHD format
-- Signing key
+- Unique build ID.
+- Manifest containing version, kernel version, size, release details and CVE manifest.
+- Software BOM package manifests (included packages, dependencies, patches).
+- Signed Image in raw.gz format.
+- Image in VHD format.
+- Signing key.
 
 
 ## Packaging
@@ -138,9 +138,9 @@ Device          Start    End      Sectors   Size  Type
 ...raw3         3145728  4192255  1046528   511M  Linux filesystem
 ```
 
-- The first partition is the EFI boot partition
-- The second partition contains the read-only rootfs filesystem
-- The third partition contains the persistent filesystem
+- The first partition is the EFI boot partition.
+- The second partition contains the read-only rootfs filesystem.
+- The third partition contains the persistent filesystem.
 
 UKI (Unified Kernel Image) is an EFI executable that bundles several components, reducing
 the number of artifacts and making updates to the operating system easier to manage.
@@ -195,8 +195,8 @@ The `layout.env` defines the `tmpfs` and persistent bind mounts for the image. B
   /etc/otelcol
 ```
 
-- The `/var` directory requires to be writable as its content changes during normal operation (logs, cache, OS runtime data, persistent application data and temporary files)
-- The `/etc/lp` holds assets and configuration for the system's printing subsystem
+- The `/var` directory requires to be writable as its content changes during normal operation (logs, cache, OS runtime data, persistent application data and temporary files).
+- The `/etc/lp` holds assets and configuration for the system's printing subsystem.
 - The `/etc/node-agent` and `/etc/cluster-agent` and `/etc/health-check` are required for the Open Edge Platform's baremetal agents for configuration data.
 - The `/etc/telegraf` and `/etc/otelcol` are for telemetry data and configuration for the `telemetry-agent` and `observability-agent` required by the Open Edge Platform.
 - `/etc/caddy` is the ephemeral data required by the reverse-proxy required by the Open Edge Platform to communicate with the backend service(s).
@@ -225,8 +225,8 @@ PERSISTENT_BIND_PATHS="
   /var/lib/rancher"
 ```
 
-- Several key directories required for the OS to be writable for normal system operations are kept as persistent bind paths such as `/etc/fstab`, `/etc/environemnt`, `/etc/hosts`, `/etc/pki`, `/etc/ssh`, `/etc/systemd`, `/etc/udev`, `/etc/sysconfig`, `/etc/netplan`
-- The Kubernetes distribution used for Open Edge platform uses Rancher's RKE2 and requires additional bind mounts such as `/etc/rancher`, `/etc/cni`, `/etc/kubernetes`, `/var/lib/rancher`
+- Several key directories required for the OS to be writable for normal system operations are kept as persistent bind paths such as `/etc/fstab`, `/etc/environemnt`, `/etc/hosts`, `/etc/pki`, `/etc/ssh`, `/etc/systemd`, `/etc/udev`, `/etc/sysconfig`, `/etc/netplan`.
+- The Kubernetes distribution used for Open Edge platform uses Rancher's RKE2 and requires additional bind mounts such as `/etc/rancher`, `/etc/cni`, `/etc/kubernetes`, `/var/lib/rancher`.
 
 ## Bare Metal Agents
 
@@ -275,10 +275,14 @@ One partition is designated as active and is used during system boot via EFI and
 When a new update is available, the following steps occur:
 
 - The new image is downloaded and then verified for integrity and authenticity.
-Once verified, the new image is written to the inactive partition.
+
+  Once verified, the new image is written to the inactive partition.
+
 - The bootloader (systemd-boot) is then reconfigured to boot from this updated partition, which will become the new active partition upon the next reboot.
+
 - Rollback Capability:
-Integrated within systemd-boot is the ability to detect boot failures. If the system fails to boot from the new image, the bootloader can automatically rollback to the previous, stable partition, ensuring continuous system availability.
+
+  Integrated within systemd-boot is the ability to detect boot failures. If the system fails to boot from the new image, the bootloader can automatically rollback to the previous, stable partition, ensuring continuous system availability.
 
 ### Benefits of This Approach
 

docs/developer-guide/contribution.md

@@ -5,9 +5,9 @@ community to support adding new features, optimizing, and improving security.
 
 There are many areas in which you can contribute, such as:
 
-1. the build infrastructure pipeline
-1. new features and functionality in new or existing microvisor image definitions
-1. support for new edge platforms
+1. The build infrastructure pipeline.
+2. New features and functionality in new or existing microvisor image definitions.
+3. Support for new edge platforms.
 
 ## New Features
 
@@ -28,33 +28,33 @@ General contribution guidelines to Open Edge platform can be found [TODO]
 
 ### Update of Edge Node Agents
 
-1. If a new package has to be released, follow below steps to ensure the package is available in the artifactory.
+1. If a new package has to be released, follow these steps to ensure the package is available in the artifactory:
 
-    1. Checkout the tag for your agent which has to be released
-    1. cd into your agent's directory
-    1. Invoke `make tarball`
-    1. Upload tarball from `build/artifacts` to the tarball repository
+    a. Checkout the tag for your agent which has to be released.
+    b. cd into your agent's directory.
+    c. Invoke `make tarball`.
+    d. Upload tarball from `build/artifacts` to the tarball repository.
 
-1. Update the respective spec file in SPECS/<agent-name> directory. Example : `SPECS/node-agent`.
+2. Update the respective .spec file in SPECS/<agent-name> directory. Example : `SPECS/node-agent`.
 
-1. Bump the release number declared in the top section of the spec file if on the same version. Else, update the release version and set the number to 1.
+3. Bump the release number declared in the top section of the .spec file if on the same version. Else, update the release version and set the number to 1.
 
-1. Update `env_wrapper.sh` and the spec file if there are new configurations to be added or installation changes.
+4. Update `env_wrapper.sh` and the .spec file if there are new configurations to be added or installation changes.
 
-1. Update the changelog to ensure the version and release number are mentioned correctly as well.
+5. Update the changelog to ensure the version and release number are mentioned correctly as well.
 Example :
 
     ```bash
     * Tue Mar 25 2025 Andrea Campanella <andrea.campanella@intel.com> - 1.5.11-2
     - Move from RSTYPE to RS_TYPE in wrapper for node-agent
     ```
 
-1. Generate sha256sum of all files that have been updated.
+6. Generate sha256sum of all files that have been updated.
 Example : `sha256sum ./SPECS/node-agent/env_wrapper.sh`
 
-1. Update the signature file name `<agent-name>.signatures.json`. Example : `node-agent.signatures.json`.
+7. Update the signature file name `<agent-name>.signatures.json`. Example : `node-agent.signatures.json`.
 
-1. Update `cgmanifest.json`. You can use a script to do it, if you have an rpm environment. Else, update the version and download the URL manually. Example commands to update using a manifest:
+8. Update `cgmanifest.json`. You can use a script to do it, if you have an rpm environment. Else, update the version and download the URL manually. Example commands to update using a manifest:
 
     ```bash
     python3 -m pip install -r ./toolkit/scripts/requirements.txt
@@ -71,14 +71,14 @@ planned releases.
 Edge Microvisor Toolkit releases every 6 weeks. Here are the details:
 
 **every 6 weeks:**
-- RPM updates including new RPMs or patches to existing RPMs
-- Exception releases to address critical bugs/CVEs
+- RPM updates including new RPMs or patches to existing RPMs.
+- Exception releases to address critical bugs/CVEs.
 
 **every 12 weeks:**
-- ISO image + RPM release
+- ISO image + RPM release.
 
 **every quarter:**
-- RAW/VHD (+RPMs delta) image release
+- RAW/VHD (+RPMs delta) image release.
 
 ## Contribution license
 

docs/developer-guide/get-started.md

@@ -4,30 +4,28 @@ Edge Microvisor Toolkit is a lightweight, container-first Linux distribution
 optimized for Intel® architecture. It provides a secure and high-performing environment for
 deploying edge workloads across multiple deployment models.
 
-This section provides its overview in terms of both the Operating System and the build pipeline.
-See what usage scenarios you can choose, in the description below, and move on to:
-
-* [Build an Edge Microvisor Toolkit Image](./get-started/building-howto.md)
-* [Install Edge Microvisor Toolkit](./get-started/installation-howto.md)
-
+The section provides an overview of both the operating system and build pipelines.
+Once you have decided on the usage scenarios presented below, you can move on to:
 
+- [Build an Edge Microvisor Toolkit Image.](./get-started/building-howto.md)
+- [Install Edge Microvisor Toolkit.](./get-started/installation-howto.md)
 
 ## Usage Scenarios
 
-Edge Microvisor Toolkit can be used for standalone edge node deployments or with Edge
-Orchestrator, a complete integrated system providing full lifecycle management for your edge
-devices, including remote deployment and management of Kubernetes applications.
-
 This section outlines the key usage models intended for the initial release of
 Edge Microvisor Toolkit.
 
+It can be used for standalone edge node deployments or with Edge
+Orchestrator, a complete integrated system providing full lifecycle management for your edge
+devices, including remote deployment and management of Kubernetes applications.
+
 ### Standalone Developer Edge Node
 
 To create a custom developer build of Edge Microvisor Toolkit, follow the steps below:
 
 - Install the mutable OS via ISO image that includes only essential pre-installed packages, providing a ready-to-use base environment.
 - Install additional RPM packages, using DNF to tailor the OS to your specific needs.
-- Update installed RPMs regularly to stay up-to-date in the OS, for package updates, kernel updates, security vulnerability fixes and bug fixes
+- Update installed RPMs regularly to stay up-to-date in the OS, for package updates, kernel updates, security vulnerability fixes and bug fixes.
 - Build a custom OS image, using the OS toolkit and available packages, which enables you to:
   - Configure the system for specialized workloads or environments.
   - Experiment with simplified or enhanced configurations tailored for your specific workloads.
@@ -49,7 +47,9 @@ The supported package repository offers additional `rpm` for tailoring the image
 
 ### Standalone Edge Node
 
-The standalone edge node uses the standard immutable build and provides an ISO image that can be flashed to a USB device and installed on edge nodes. It installs the microvisor and Kubernetes to the edge node with the essential functionality to run a single node cluster. The edge node will serve as both control- and worker node. Additional worker nodes can be added to the cluster through Kubernetes. Future releases will allow standalone edge nodes to join an existing Edge Orchestrator Toolkit backend deployed on-prem or in the cloud to support scale out and management of larger infrastructures. The Standalone Edge Node enables you to quickly get an edge node up and running without deploying backend services, ready to deploy Kubernetes applications through `kubectl`, `helm`, or Kubernetes web dashboard.
+The standalone edge node uses the standard immutable build and provides an ISO image that can be flashed to a USB device and installed on edge nodes. It installs the microvisor and Kubernetes to the edge node with the essential functionality to run a single node cluster. The edge node will serve as both control and worker node. Additional worker nodes can be added to the cluster through Kubernetes.
+
+Future releases will enable standalone edge nodes to join an existing Edge Orchestrator Toolkit backend deployed on-prem or in the cloud to support scale out and management of larger infrastructures. The Standalone Edge Node enables you to quickly get an edge node up and running without deploying backend services, ready to deploy Kubernetes applications through `kubectl`, `helm`, or Kubernetes web dashboard.
 
 ```{admonition} The standalone edge node does not support the real-time version currently.
 :class: note

docs/developer-guide/get-started/building-howto.md

@@ -6,13 +6,13 @@ facilitate creating `rpm` based OS images supporting a variety of different imag
 The toolkit has an `imageconfig` construct in the `json` format that defines the resulting
 image characteristics, such as:
 
-- Partitioning table type and size
-- The different partitions and their types (such as EFI, rootfs, etc.) and settings, file system (`fat32`, `ext4` etc.) and size
-- Reference to `packagelists` which defines what packages (i.e. `rpms`) should be included in the image
-- Additional configuration files that should be embedded in the image (e.g. network-, systemd configurations)
-- Any required post installation scripts that should be executed once the image has been generated
-- Kernel options and command line
-- Final configuration properties that should be applied (e.g. enable full disc encryption, immutable image, second stage bootloader provider, purge documentation etc.)
+- Partitioning table type and size.
+- The different partitions and their types (such as EFI, rootfs, etc.) and settings, file system (`fat32`, `ext4` etc.) and size.
+- Reference to `packagelists` which defines what packages (i.e. `rpms`) should be included in the image.
+- Additional configuration files that should be embedded in the image (e.g. network-, systemd configurations).
+- Any required post installation scripts that should be executed once the image has been generated.
+- Kernel options and command line.
+- Final configuration properties that should be applied (e.g. enable full disc encryption, immutable image, second stage bootloader provider, purge documentation etc.).
 
 
 Before you can build OS images you need to build the toolchain and make sure to
@@ -74,7 +74,7 @@ files from the `imageconfig`.
 ### Example: Adding Nano
 
 The following example shows how to add `nano` as an alternative text editor to the image.
-You can add the packages for which SPEC files already exist. Simply include them in an
+You can add the packages for which .spec files already exist. Simply include them in an
 existing `packagelist` file, or create a new one and add it to the `imageconfig`.