Hi
>>We will use the Roles and Profiles ideas suggested by Kashif with a naming scheme like Role::RALPP::Prod::<name> and Profile::RALPP::Prod::<name>
>>Not sure of the details here but we do indeed have hostgroup modules like.
Profile and Role mode is based on this blog
http://www.craigdunn.org/2012/05/239/
Cheers
Kashif
________________________________________
From: Testbed Support for GridPP member institutes [[log in to unmask]] on behalf of Steve Traylen [[log in to unmask]]
Sent: Wednesday, June 19, 2013 10:18 AM
To: [log in to unmask]
Subject: Re: Thoughts on Puppet before we get too far in
On Jun 19, 2013, at 11:00 AM, Chris Brew wrote:
> Hi All,
>
Hi Chris,
> We are going to start using puppet in anger as we start developing some production SL6 services (worker nodes for instance), and I thought it would be worthwhile listing out some of the design decisions we're making before we get too far in so more experienced admins can tell us what's stupid. The plan is to implement this from scratch for the SL6 deployment and not try to translate our existing cfengine set-up.
>
> So here we go.
>
> 1) We will use Puppet 3.2 from puppet labs rather than the 2.6 version from EPEL
We are migrating to puppet 3.2 (from 2.7) at this second in fact. 2.6 is a dead duck basically and some pretty critical modules like openstack are dropping
support for it (and 2.7) in fact.
> 2) We will use the Roles and Profiles ideas suggested by Kashif with a naming scheme like Role::RALPP::Prod::<name> and Profile::RALPP::Prod::<name>
Not sure of the details here but we do indeed have hostgroup modules like.
hostgroup::fts::production as a single class for a host that then include bits of cern paramatizaion of modules (what you call atoms below.)
> 3) We're going to extend the naming scheme and call the modules that actually configure things "Atoms" (the best name we could come up with over Coffee) with a similar naming convention i.e. Atom:RALPP:Prod:<name>
> 4) We will use hiera and templates to abstract out as much site local config as possible from the Atoms
>
> We will also probably use augaus to edit files in place where using templates is not practical but don't know enough about this yet to be certain on that.
>
A bit of both I would say.
> What other extra modules are people using that you've found useful? Looking around there often seem to be several tools/modules/ways of doing the same things so choosing a common approach would help in sharing.
>
Our current list of modules in our repo is http://pastebin.com/8DWD2m4R , I'm well aware of the fact that not enough of these are making it http://github.com/cernops for public consumption nor are
we tracking well updates from upstream where we have taken stuff from. However it seems
we are about to massively reorganise our git repositories for other reasons which will make getting stuff to cernops massively easier and in fact cernops will be used live trivially. In a nutshell we are moving
from a single git repository to an aggregate of many of git repositories per module - see puppet-librarian - https://github.com/rodjek/librarian-puppet. We don't know the exact solution yet as we only gave up on the
current model a few days ago, there extra complexity is mainly due to having to many fingers in the puppet configuration with a lack of total knowledge of changes.
> Thanks,
> Chris.
>
>
> --
> Dr Chris Brew
> Scientific Computing Manager
> Particle Physics Department
> STFC - Rutherford Appleton Laboratory
> Harwell Oxford,
> Didcot
> OX11 8TZ
> +44 1235 446326
>
>
>
> --
> Dr Chris Brew
> Scientific Computing Manager
> Particle Physics Department
> STFC - Rutherford Appleton Laboratory
> Harwell Oxford,
> Didcot
> OX11 8TZ
> +44 1235 446326
>
>
> --
> Scanned by iCritical.
|