Paul, +1 for the upload a template as SYSTEM. At least in 4.2 we have a global setting to specify which template is to be used, but indeed there is no way to upload or change a template into SYSTEM. This has to be done by means of DB change.
-NT Kind regards, Nuno Tavares Senior DevOps Infra Specialist LeaseWeb Technologies B.V. T: +31 20 316 0235 E: n.tava...@tech.leaseweb.com W: www.leaseweb.com<http://www.leaseweb.com> Luttenbergweg 8, 1101 EC Amsterdam, Netherlands ________________________________ From: Paul Angus [paul.an...@shapeblue.com] Sent: Monday, February 22, 2016 1:39 PM To: dev@cloudstack.apache.org Subject: RE: [DISCUSS] Keeping system vms up to date I think that there are two parts to this - creating system VMs and installing them. The systemvms need to have the automated build with versioning 4.5.2-1234 (I'd like to see that shown in log on screen of all system vms) + we should have some direct control available in CloudStack of which template is the system VM template. And be able to upload a template as 'SYSTEM'. <http://www.shapeblue.com> Paul Angus VP Technology , ShapeBlue d: +44 203 617 0528 | s: +44 203 603 0540<tel:+44%20203%20617%200528%20|%20s:%20+44%20203%20603%200540> | m: +44 7711 418784<tel:+44%207711%20418784> e: paul.an...@shapeblue.com | t: @cloudyangus<mailto:paul.an...@shapeblue.com%20|%20t:%20@cloudyangus> | w: www.shapeblue.com<http://www.shapeblue.com> a: 53 Chandos Place, Covent Garden London WC2N 4HS UK Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. -----Original Message----- From: Nux! [mailto:n...@li.nux.ro] Sent: Monday, February 22, 2016 9:37 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Keeping system vms up to date 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" <terbol...@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 Find out more about ShapeBlue and our range of CloudStack related services: IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> | CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
