On Mon, Feb 22, 2016 at 1:18 PM, Rene Moser <m...@renemoser.net> wrote:
> Hi > > I don't like the idea cloudstack management handles the "apt-get update > && apt-get upgrade" (I am -1 for this solution) or at least I would like > to disable it by configuration, if we go this direction. > It should by no means be mandatory, and wether or not it should be default on is up for debate. I have no strong opinion about the latter. Adding a boilerplate in the install/admin docs that says "If you have no other tools in place to handle system vm updates, consider enabling this option: x.y.z" is good enough for me. This is supposed to be a way for all those who don't have any other/better means of doing this, not a mandatory/forced way of doing it for everyone else. We use ansible (what a surprise) to update the VR and also add some > custom patches to it. We have a dynamic inventory getting all the VR > with linklocal IP as ssh host and regulary run playbooks to these VRs > running by a jenkins job. > > This sounds a bit kind of a hack at the beginning but it has the > advantage that we are able to run the very same playbooks also against > our test and stage cloud. Which gives a good feeling. > > I would like to see an api for download and update latest system-vm > template. AFAIK this is still not solved (without touching DB) to update > system-vm templates having same version. > > This way it would be up to the user to handle the upgrade and to think a > bit further we could also define a rollback scenario (use previous > template). > > This thread is ment to discuss varies ways to achieve the goal, I did not mean to propose a single way of doing it. Pushing an ansible inventory script (that works with all major ACS hypervisors) and a playbook is another option. -- Erik
