On Mon, Jul 30, 2012 at 10:26:36AM +0300, Ohad Levy wrote: > On 07/30/2012 10:18 AM, Ivan Necas wrote: > > > >----- 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 assuming you had a puppet structure that has module-package class > style i guess you could pull it off, but it needs to make > assumptions on the manifest (e.g. written in a certain way) and that > there are no references within the puppet code to other non included > resources. > > you are right that's its possible, but we would expecting our users > to build it in a certain way, and if they include the wrong classes > there might be unexpected results. > > Also, do you assume this works in a masterless mode? (e.g you would > need to distribute the manifests to the image + ensure that the > manifests can work without a master). > > and more than that, we would probably need a cleanup script to be > executed on the instance regardless.
I can tell you with 100% certainty that we have users right now who want to operate in this way (doing a lot of work in the image build environment rather than post-boot). I'm not claiming it is a *good* way to operate, or that we should encourage people to do it, but I think we have no choice but to support it at least to a degree. I do agree with Bryan that we should prioritize the thin-JEOS fat-post-boot case wherever possible. Take care, --Hugh > >> > >>> > >>>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? > > we did discuss several times to reuse foreman templates as an post > image / post first boot template engine processor, so it would be > done in the exact same way like its done for bare metal/ vms. > > we also need to figure out how to deploy the initial certificates. > (e.g. if we allow the instances to reach out or are we 'pushing' the > certs to them etc). > in foreman for vm/bare metals we let the hit a url (with a uuid) and > for ec2 / openstack we simply ssh into the instances. > > Ohad > > > >-- 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 > >>> > >>> > >> > > > > > >_______________________________________________ > >katello-devel mailing list > >[email protected] > >https://www.redhat.com/mailman/listinfo/katello-devel > > > > _______________________________________________ > katello-devel mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/katello-devel -- == Hugh Brock, [email protected] == == Engineering Manager, Cloud BU == == Aeolus Project: Manage virtual infrastructure across clouds. == == http://aeolusproject.org == "I know that you believe you understand what you think I said, but I’m not sure you realize that what you heard is not what I meant." --Robert McCloskey
