Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Mon, 22 Feb 2016 09:36:36 +0000 (GMT)
From: Nux! <nux@li.nux.ro>
To: dev@cloudstack.apache.org
Message-ID: <738440032.58182.1456133796839.JavaMail.zimbra@li.nux.ro>
In-Reply-To: 
 <CAP997UfDer7hWfu2pNWYKwsOaUktORnVDhuk6TnWtY_Fct7Btw@mail.gmail.com>
References: 
 <CAP997UfDer7hWfu2pNWYKwsOaUktORnVDhuk6TnWtY_Fct7Btw@mail.gmail.com>
Subject: Re: [DISCUSS] Keeping system vms up to date
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thread-Topic: Keeping system vms up to date
Thread-Index: SE1E0Gz2FCKQC0mlKFixD5il33vcyw==

Hi Erik,

Legit worry point.

IMHO the updates of the VR and so on should be the job of whoever runs the cloud, just like it's the same person's job to keep the HVs up to date.

I'm sure it's possible to get all the VRs registered in some sort of ansible/puppet thingy and keep track of them this way.

Regarding up to date VM templates, I think part of the problem is solved as Jenkins is building 4.6 frequently:
http://jenkins.buildacloud.org/job/build-systemvm64-master/

It might just be a matter of uploading those to cloudstack.apt-get.eu.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Erik Weber" <terbolous@gmail.com>
> To: "dev" <dev@cloudstack.apache.org>
> Sent: Monday, 22 February, 2016 08:53:48
> Subject: [DISCUSS] Keeping system vms up to date

> 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