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.
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
