cloud Digest, Vol 36, Issue 24

[Tim Bell]

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 configurations.

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)

Tim

> -----Original Message-----
> From: cloud-bounces at lists.fedoraproject.org [mailto:cloud-
> bounces at lists.fedoraproject.org] On Behalf Of Steve Loranz
> Sent: 18 December 2012 19:13
> To: herrold at owlriver.com
> Cc: cloud at lists.fedoraproject.org
> Subject: Re: cloud Digest, Vol 36, Issue 24
> 
> Russ,
> 
> 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
> provisioning.
> 
> -steve
> 
> 
> 
> On Dec 18, 2012, at 11:39 AM, cloud-request at lists.fedoraproject.org wrote:
> 
> > Message: 7
> > Date: Tue, 18 Dec 2012 12:38:43 -0500 (EST)
> > From: R P Herrold <herrold at owlriver.com>
> > To: Fedora Cloud SIG <cloud at lists.fedoraproject.org>
> > Cc: boxgrinder-dev at boxgrinder.org
> > Subject: future of Boxgrinder ... building cloud images
> > Message-ID: <alpine.LRH.2.02.1212181230030.6319 at 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5215 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20121218/22f94eab/attachment-0001.p7s>