Purpose: Further optimise SystemVM template generation, lifecycle, and upgrades.
With https://github.com/apache/cloudstack/pull/4329 in 4.16, significant systemvmtemplate lifecycle changes were introduced to simplify systemvmtemplate install and upgrades, as well as making it cloud-init enabled for CKS use-case. In addition, the management server ssh public key is now also patched via cmdline string.
Any major feature/change should be done in the main branch, however, optimisations and operational improvements can be done in current LTS branch for future minor releases.
- Use of squashfs for in-place upgrades.
- Unify initial patching via cloud-init+config-drive and deprecate/remove cmdline.
- Install/patch non-common userspace dependencies upon patching via scp/ssh (for ex. jre deb pkg etc) or serve host static repo/cache in mgmt server web server
- To build systemvmtemplate during mvn/packaging itself so hosting is no longer required
- CKS changes: since CKS is not tied with systemvmtemplates, we ca:
- Explore: Make CKS not use cmdline string-based patching, switch to user-data or config-drive alone (Vmware disks issue); for this to happen change cloud-early-config to by default treat the template as cloud-init enable template if/when cmdline can be obtained/processed
In the following sections, we define the scope and high-level spec and well as discuss/propose design & implementation.
SystemVM build and packaging changes
- Explore debootstrap, nbd and chroot based systemvm template building. PoC shows promise, builds template under 5mins. (vs 30-60mins before), refer to PoC tree for export logic too.
- During packaging, this can simplify things so if systemvm.iso is deprecated then we bundle the ova only when -D systemvm or -P systemvm is enable
SystemVM template upgrades
- Trigger auto-upgrades or installs based on ini file or some file/property specifies min. require template (compare against global setting and the pkg specific file/property). Same can be hard-coded/specified/used by mvn, so it doesn't auto-trigger upgrades when upgrades may not be necessary, esp for minor releases (say upgrade from 4.16.0->4.16.1...).
- Good to have: Old systemvmtemplates should be allowed to be removed/deleted by the admin
Since CKS is not tied with systemvmtemplates, some optimisations can be explored:
- Switch to using cloud as user instead of core, fix yml templates; and add ssh-access in the UI if/when the user selects a SSH public key
- In the UI - display CKS host image version, dockerd and other env info that may be useful for CKS users
- Document list of supported k8s versions with CKS with ACS release - add note in ACS release notes's compatibility page
- Optional / Good to have: Enable CKS by default (as CKS is turnkey with systemvmtemplates) and trigger registration of built-in CKS data iso per ACS version (this can similar to the built-in template, a quick to enable a k8s version with a ACS version)