----- Ohad Levy <[email protected]> wrote: > On 07/30/2012 10:02 AM, Ivan Necas wrote: > > > > Maybe the user preparing the puppet manifests should decide what to run > > when. That's what I do, when preparing reusable system images fo myself: > > having separated classes for preparing the image (e.g packages > > installation) and classes needed in run-time (configuration itself). No > > matter if I use stages or tag or other way to do that, at the end it's one > > class (or set if classes) to run on the template system and another classes > > for run-time. > > I don't think users would like to write their manifests twice (and test). I'm not writng nanifests twice. Just selecting classes that are save to run on the template system. > > > > > So enabling the users to make this decision of selecting classes for build > > or run time would bring him the possibility to optimize their processes the > > way they like. > > I'm all for customization and ease of use, but if you remember the the > only thing that really saves time is downloading and installing system > binaries, then what we really need to care about is packages. > > we already have a way to let the user execute something when building > the image, so i think of all that customization is already covered?
What way do you have in mind? -- Ivan > > > > > > > -- Ivan > > > > ----- Original Message ----- > > From: Ohad Levy <[email protected]> > > To: Ivan Nečas <[email protected]> > > Cc: Ian McLeod <[email protected]>, [email protected], > > [email protected] > > Sent: Sun, 29 Jul 2012 03:17:08 -0400 (EDT) > > Subject: Re: [katello-devel] Improving Aeolus + Katello integration > > > > On 07/27/2012 08:48 AM, Ivan Nečas wrote: > >> If prepared properly, puppet manifests can be applied even without the > >> master present. Especially, if the user that prepares the manifests > >> counts on the fact, that it could be run without master (which is not so > >> hard to test), he could then benefit significantly from this. He > >> probably still might want to rerun it on instance creation time, but > >> it's much faster then running against a JEOS. > > > > True, but you really want to make sure that all services are stopped > > afterwards, until firstoboot would activate/reconfigure them again. > > > > so the bottom line, > > > > creating a new custom image vs using JEOS is an optimization step (less > > time to get a new customized instance to run) due to the fact that you > > upload the content upfront, it should potentially also save some disk > > space (if you would be using snapshots). > > > > saying that, you must make sure that you have nothing specific from the > > image creation time, such as services running etc, so in reality, you > > just want the packages, nothing else. > > > > I would think that using puppet for creating the image is a good idea, > > but might not fit exactly to how puppet works, and you could consider > > adding tags [1] or run stages[2] or simply send a patch to puppet to > > auto tag packages and then you could ask puppet to install only packages. > > > > > > > > Ohad > > > > [1] http://projects.puppetlabs.com/projects/1/wiki/Using_Tags > > [2] http://docs.puppetlabs.com/guides/language_guide.html > > > > >
