Purpose: Further optimise SystemVM template generation, lifecycle, and upgrades.

With 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.


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

1.0Rohit Yadav


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)
  • No labels