All,
We've over the years create a VR that largely is stable but we've discussed the
pain of maintaining, extending, and upgrading VRs both in lists and in
user-groups and CCC conferences.
On a high-level the pain points are:
* It's difficult to debug, investigate VR for operators and support team
* Maintaining the VR code, fixing bugs, implementing features is a pain for
developers; further the xml&json databags based programming model is confusing
* Any fix or changes requires a new systemvmtemplate or VR codebase whose
patching requires restarting the VR or destroying an old VR
* No uniform VR programming API (current approach is SSH+databags and
execute a script), this makes testing VR difficult and QA in isolation is not
possible
* Users forget to register the right systemvmtemplate for a new ACS version
and upgrades fail
* Others (please share yours)?
Among these pain points my colleagues have proposed a PR targeting 4.16 [1]
that aims to unify systemvmtemplate as a building block that is bundled as part
of ACS rpm/deb/* packages which CloudStack will automatically seed/register/use
with which upgrades will be as simple as a yum update or apt-get upgrade.
Further, my colleagues and I are exploring a live patch API which in near
future that can patch a running systemvm/VR using systemvm.iso (or deprecate
systemvm.iso and use ssh/scp to patch?) without requiring to reboot/recreate
it. Hopefully, this addresses some of those pain points. We request the
community for your feedback and review/participation in the PR.
Open questions, topics to discuss and gather feedback:
* VR programming: Should we explore a new light-weight VR agent that
provides an API (restful/grpc, or CLI?), some mechanism of live patching VR
code, packages, and kernel?
* Refactoring isolated network and VPC codebases into a unified codebase
and feature sets (assumption that isolated network are largely a VPC with
single tier), does it benefit the community, users, and developers?
* Underlying OS:
* should we consider something other than Debian, any suggestions?
* or explore stable/widely used and maintained opensource router
distributions such as OpenWRT [2] which ships with a UI and CLI/configuration
system UCI [3]? The cons of the approach are a new dependency and some likely
missing packages.
* In current VR codebase, most of the effort is spent in
implementing/maintaining router packages/configure codebase which we can get
rid of by depending on a stable Linux router distro which ships with some
API/config system. Not choosing an existing router distribution means we
continue to DIY router programming+config management codebase.
* Any other ideas?
Thoughts, feedback?
[1] https://github.com/apache/cloudstack/pull/4329
[2] https://github.com/openwrt/openwrt/graphs/contributors
[3] https://openwrt.org/docs/guide-user/base-system/uci
Regards.
