I would suggest that having some sort of built in functionality tied to the management server would be a good thing, but don't make it overbearing. If operators have their own patch methodolgies right now that's fine, and they should be able to continue to use them. For smaller shops or operations teams with limited development experience an 'official' patch method would be great.
I know we've run into quite a few bugs and operations problems that required us to update the code and re-compile CloudStack, or implement some sort of hack, or wait until the next release. These options shouldn't be the norm; in other words operations teams (not development, not devops, actual sysadmins) shoulnd't need to wait on the developers to apply fixes or changes. Thank You, Logan Barfield Tranquil Hosting On Mon, Oct 6, 2014 at 1:03 PM, Leo Simons <lsim...@schubergphilis.com> wrote: > 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 > >
