On Oct 3, 2014, at 4:03 PM, 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?
We've had the same thoughts and investigated it in some detail, 78f21166c10f291fca395c6ab8d67b7137e0ea86 is about the last point before we abandoned that approach. https://github.com/schubergphilis/cloudstack/blob/78f21166c10f291fca395c6ab8d67b7137e0ea86/systemvm/patches/debian/config/opt/cloud/bin/merge.py https://github.com/schubergphilis/cloudstack/tree/78f21166c10f291fca395c6ab8d67b7137e0ea86/tools/vagrant/systemvm the idea was that all systemvm configuration would take the shape of chef data bags passed along from the management server, that would then be used to configure chef cookbooks that would be executed using chef-solo. We abandoned this approach because running chef-solo took too long and used too many resources; I think a similar argument would hold against ‘puppet apply’. The systemvm when deployed as a router is a network device and I guess in general that having heavy processes running periodically on active network devices is a bit scary. So now the "persistent config" part of our redundant vpc router branch is still using the configuration management model of converging to a desired state, but written using a less fancy but more efficient and predictable custom python script. https://github.com/schubergphilis/cloudstack/blob/feature/systemvm-persistent-config/systemvm/patches/debian/config/opt/cloud/bin/configure.py Having said all that, I agree with Logan that On Oct 3, 2014, at 5:30 PM, Logan Barfield <lbarfi...@tqhosting.com> wrote: > 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). Right now we resort to custom template builds a times, as well as various bits of cloudmonkey or marvin scripting to find and iterate over system vms and do things to them (like apply bash patches). It’s possible to do this stuff but it isn’t easy, and it would definitely be good to have a well-beaten path for operators to wander down. I’m not sure having the management server assume responsibility over some of the systemvm patching would be good: it could get into conflict with operators wanting to do their own / slightly different patching. It’d have to be an appropriately ‘open’ design which then brings with it its own set of security considerations. cheers, Leo
