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. -Sam ----- Original Message ----- From: "Tim Bell" <Tim.Bell@xxxxxxx> To: "Fedora Cloud SIG" <cloud@xxxxxxxxxxxxxxxxxxxxxxx>, herrold@xxxxxxxxxxxx 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 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@xxxxxxxxxxxxxxxxxxxxxxx [mailto:cloud- > bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Steve Loranz > Sent: 18 December 2012 19:13 > To: herrold@xxxxxxxxxxxx > Cc: cloud@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx wrote: > > > Message: 7 > > Date: Tue, 18 Dec 2012 12:38:43 -0500 (EST) > > From: R P Herrold <herrold@xxxxxxxxxxxx> > > To: Fedora Cloud SIG <cloud@xxxxxxxxxxxxxxxxxxxxxxx> > > Cc: boxgrinder-dev@xxxxxxxxxxxxxx > > Subject: future of Boxgrinder ... building cloud images > > Message-ID: <alpine.LRH.2.02.1212181230030.6319@xxxxxxxxxxxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/cloud _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud
