I agree with what Tim said. You don't need to rebuild images every time there is a
change to the configuration management system, but it will drastically reduce the time
required to build a new host if the starting point is close to the final, built machine.
I've talked to a number of organizations that do weekly automated rebuilds of their
"golden images" so their configuration might drift over the week, but old and
new hosts (with their subsequent base images) will be in the exact same state because the
entirety of their desired state is in CM.
----- Original Message -----
From: "Tim Bell" <Tim.Bell(a)cern.ch>
To: "Fedora Cloud SIG" <cloud(a)lists.fedoraproject.org>,
Sent: Tuesday, December 18, 2012 3:03:51 PM
Subject: RE: cloud Digest, Vol 36, Issue 24
I don’t see an image factory approach and a puppet approach as being competitors.
We need to find ways to produce common images for multiple hypervisors in an automated
fashion. Booting VMs and then waiting 30 minutes for a yum update (or even worse, waiting
an hour for Office 2013 to install) is not exactly elastic computing so a regular run of
standard version builds is a key function.
Puppet provides the function to take the base images and create the custom
Organising up-to-date standard images for the common platforms and then the
'last-mile' via puppet seems efficient.
(I use Puppet as an example, Chef would be equally appropriate)
From: cloud-bounces(a)lists.fedoraproject.org [mailto:cloud-
bounces(a)lists.fedoraproject.org] On Behalf Of Steve Loranz
Sent: 18 December 2012 19:13
Subject: Re: cloud Digest, Vol 36, Issue 24
Apologies if I'm misinterpreting what you're saying here, but I think that
imagefactory can do what you are looking for. The core of imagefactory
supplies the REST interface, CLI, provides some storage for built images, and
manages dispatching work to the plugins. The plugins do the heavy lifting and
these are separated as OS and Cloud plugins. We currently have one OS plugin
that started off as Fedora/RHEL specific and uses Oz to create a base JEOS
image. All of the customization that creates a target image from a base image
is done by a cloud plugin.
So, you could have a very minimal TDL that creates a minimal base JEOS
image. You could then supply your own Cloud plugin for your virt service that
does the customization you want.
The imagefactory project is packaged separately from Aeolus and can be used
without any other component from Aeolus. Oz is used by the current OS plugin,
but that plugin can be replaced by another that uses some other method of
On Dec 18, 2012, at 11:39 AM, cloud-request(a)lists.fedoraproject.org wrote:
> Message: 7
> Date: Tue, 18 Dec 2012 12:38:43 -0500 (EST)
> From: R P Herrold <herrold(a)owlriver.com>
> To: Fedora Cloud SIG <cloud(a)lists.fedoraproject.org>
> Cc: boxgrinder-dev(a)boxgrinder.org
> Subject: future of Boxgrinder ... building cloud images
> Message-ID: <alpine.LRH.2.02.1212181230030.6319(a)puneyrf.bjyevire.pbz>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> On Tue, 18 Dec 2012, David Busby wrote:
>> I think you'll find it hard to get any traction here kickstarts
>> especially in the "cloud front" are used increasingly less in favour
>> of bootstrapping an instance with puppet / chef for provisioning
>> above and beyond the base os.
> well known, but the non-idempotent, and 'successive approximation'
> nature of such solutions converging to a configuration makes such
> tools less compelling than a using kickstart against a 'repoclosed'
> universe of packages.
> I am interested in the building of 'base JEOS' images to our
> virtualization service, that are then handed off as 'gold masters' for
> clinets who THEN inject their certificates, keys and credentials.
> There are of course security and liability implications in releasing
> images keyed to masters not known to the end user, and kickstart
> solves them well, and the devops tools less well
>> The tdl format is somewhat of a stop gap between kickstarts and fully
>> fledged provisioning I have found, and a good project providing many
>> example tdls is the Aeolus project: http://www.aeolusproject.org/
> I am generally aware of it as a project, and I think follow a blog on
> the matter, but not a mailing list. I'll remedy that and read for a
> bit. But packaging Ruby has been a 'bear' and seemed to be 'not well
> solved' yet. I have no aversion to Ruby
> -- we use it on a project internally -- but adding random 'gems' not
> well understood as to versioning and security model, is troubling
> -- Russ herrold
cloud mailing list
cloud mailing list