From efca83730b3f957f2b6d7f394c591a25e061564e Mon Sep 17 00:00:00 2001 From: "Anderson, Craig (ca846m)" Date: Fri, 12 Nov 2021 02:40:05 -0800 Subject: [PATCH] Cleanup and removal of downstream references Change-Id: I3da28cb4a92f9cab25ea0ece98f9831bbea0bff2 --- README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index e1f585c..ca227ef 100644 --- a/README.md +++ b/README.md @@ -76,26 +76,26 @@ The `SKIP_MULTI_ROLE` build flag is useful if you would like to test local updat sudo make SKIP_MULTI_ROLE=true build ``` -Similiarly, osconfig and livecdcontent roles can be skipped using `SKIP_OSCONFIG_ROLE` and `SKIP_LIVECDCONTENT_ROLE` respectively. `SKIP_LIVECDCONTENT_ROLE` may be useful in combination with `SKIP_MULTI_ROLE` if you want to test out playbook changes to `osconfig` (however, it won't show up in the final bootable ISO image unless you don't skip `SKIP_LIVECDCONTENT_ROLE`). +Similarly, osconfig and livecdcontent roles can be skipped using `SKIP_OSCONFIG_ROLE` and `SKIP_LIVECDCONTENT_ROLE` respectively. `SKIP_LIVECDCONTENT_ROLE` may be useful in combination with `SKIP_MULTI_ROLE` if you want to test out playbook changes to `osconfig` (however, it won't show up in the final bootable ISO image unless you don't skip `SKIP_LIVECDCONTENT_ROLE`). # Division of Configuration Management responsibilities Configuration management of the base OS is divided into several realms, each with their own focus: 1. Image-builder configuration data, i.e. data baked into the QCOW2 base image. The following should be used to drive this phase: - 1. The storage and compute elements of NCv1 host and hardware profiles (kernel boot params, cpu pinning, hugepage settings, disk partitioning, etc), and - 1. the NCv1 divingbell apparmor, security limits, file/dir permissions, sysctl, and - 1. custom-built kernel modules (e.g. dkms based installations, i40e driver, etc) + 1. The storage and compute elements of host/hardware profiles (kernel boot params, cpu pinning, hugepage settings, disk partitioning, etc), and + 1. Common operating system configurations applicable to all (or most) deployment scenarios. + 1. Custom-built kernel modules (e.g. dkms based installations, i40e driver, etc) 1. Necessary components for the node’s bootstrap to k8s cluster, e.g. k8s, CNI, containerd, etc - 1. any other operating system setting which would require a reboot or cannot otherwise be accommodated in #2 below + 1. Any other operating system setting which would require a reboot or cannot otherwise be accommodated in #2 below -1. cloud-init driven configuration for site-specific data. Examples include: +1. Cloud-init driven configuration for site-specific data. Examples include: 1. Hostnames, domain names, FQDNs, IP addresses, etc 1. Network configuration data (bonding, MTU settings, VLANs, DNS, NTP, ethtool settings, etc) 1. Certificates, SSH keys, user accounts and/or passwords, etc. 1. HCA (host-config agent) for limited day-2 base-OS management - 1. Cron jobs, such as the Roomba cleanup script used in NCv1, or SACT/gstools scripts + 1. Cron jobs 1. Possible overlapping of configuration-management items with #1 - #2, but for zero-disruption day-2 management (kept to a minimum to reduce design & testing complexity, only essential things to minimize overhead.) 1. Eventually HCA may be phased out if #1 and #2 become streamlined enough and impact minimized to the degree that SLAs can be met, and use of HCA may be reduced or eliminated over time.