>From a service provider perspective I would agree that this issue needs to be addressed as soon as possible. In the short term it would make sense for CloudStack to release a patched SystemVM template and upgrade instructions. In the long term I think the better option would be to allow the templates to be patched more easily (i.e. make changes and save the template).
Thank You, Logan Barfield Tranquil Hosting On Fri, Oct 3, 2014 at 10:03 AM, Alex Brett <alex.br...@citrix.com> wrote: > On 03 October 2014 13:52, Adrian Lewis [adr...@alsiconsulting.co.uk] > wrote: > > The only solution I can think of is to 'apt-get update bash' on every > > system VM but clearly these get fired up dynamically. Is it possible to > > boot the template, make modifications and then use as a replacement > system > > VM? Are there processes that happen on boot that only happen once and > > therefore need resetting to recreate the template? > > This isn't a quick fix, so not suitable for this specific issue, but > something I've wondered for a while is rather than keep having to build new > system VM templates for every small change, would we be better integrating > a tool such as Puppet / Chef, so we can bring a system VM 'up to date' when > it boots, as long as it's the right 'base'. > > What I'm thinking here (using Puppet terminology as that's what I'm > familiar with, but could be any similar mechanism or even just a simple > script) is when the system VM loads up, it connects to the management > server and retrieves a manifest, which it then applies. That manifest would > specify: > - Packages to update (including if necessary any apt/yum repo information) > - Config files to put in place > - Anything else required like starting any services etc > > While it would slightly delay the boot process, it would ensure that on > e.g. upgrade, you don't have to immediately replace your system VM template > unless a substantial change (e.g. base system VM distro / partition layout) > has been made. You could still bring in an updated template to speed things > up, but it would be far less urgent to do so... > > Any thoughts on this anybody? > > Alex >
