As of 4.6 or so, we don't really need to distribute new system vm templates all that often, and that is great for upgrades, but less so from a security perspective.
With the current approach we ship old system vm templates, with out of date packages, and there is currently no good out of the box way to handle that. There is a few ways to handle it, including, but not limited to: 1) Introduce a configuration value that specifies if you want to run apt-get update && apt-get upgrade on boot. This slows down deployments and will only get worse as times passes and there are more packages to update. An alternative is to specify a list of packages we _HAVE_ to keep updated and only update those. 2) Package new system vms for all releases, but not bump the version number (or introduce a patch version number). This is ment to ensure that new cloud deployments are somewhat up to date, but won't update existing ones nor ensure that the deployment is kept up to date. 3) Add an optional? cronjob that does apt-get update && apt-get upgrade, the downside is that you risk having some downtime for certain services. 4) A combination of the previous 3. And most likely other options I haven't thought of. I feel we need to address this somehow or else we risk ending up as a very negative headliner when the right (or wrong) bug/exploit gets out and takes down a bunch of clouds.. -- Erik
