[katello-devel] Improving Aeolus + Katello integration

Tue Jul 31 13:39:07 UTC 2012

----- Original Message -----
> From: "Hugh Brock" <hbrock at redhat.com>
> To: "Ohad Levy" <ohadlevy at redhat.com>
> Cc: aeolus-devel at fedorahosted.org, katello-devel at redhat.com
> Sent: Tuesday, July 31, 2012 8:29:45 AM
> Subject: Re: [katello-devel] Improving Aeolus + Katello integration
> 
> 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 <ohadlevy at redhat.com> 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.

Not that we would position Aeolus without Katello on the product side (CloudForms), but if we had customers running their own systems management facility (HP, BMC, IBM, Home Grown Puppet) that wanted to use Aeolus for self-service and image building then having some fancy image management features in aeolus would be important.

> 
> 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 <ohadlevy at redhat.com>
> > >>>To: Ivan Nečas <inecas at redhat.com>
> > >>>Cc: Ian McLeod <imcleod at redhat.com>,
> > >>>aeolus-devel at fedorahosted.org, katello-devel at redhat.com
> > >>>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
> > >katello-devel at redhat.com
> > >https://www.redhat.com/mailman/listinfo/katello-devel
> > >
> > 
> > _______________________________________________
> > katello-devel mailing list
> > katello-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/katello-devel
> 
> --
> == Hugh Brock, hbrock at redhat.com                                   ==
> == 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
> 