Introduction

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.

References:

• Discussed in the CCC talk Next-Gen VR https://rohityadav.cloud/files/talks/ccc21-vr-agent.pdf
• VR agent design doc: Next-Gen Virtual Router and VR Agent

Future work

• 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

Document History

Feature Specifications

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

CKS Changes

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)