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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud
