> Hum, I get the feeling there is more than just this removal scenario
> that's bugging you. However, there are rather elegant solutions in the
> DSL for that, so I'll elaborate on this and maybe inspire you to some
> other approaches that may help with other problems as well.
You are correct, the removal senario is not the only issue.
Ultimately I would like to roll in service and configuration awareness
so that as long as you know what package you want to install, you can
easily make sure any associated service is running and that you have
put config files is the right place. I'm a long way from that, but
this is just the first step in the journey and I think even by itself
it will prove to be beneficial to the puppet community as a whole.
> First off, don't rely on dynamic scoping (i.e. variables being available
> in included classes) if it's at all possible.
I agree whole heartedly on this. Technically, I'm not relying on
dynamic scoping. If the variables are not available in the included
class, things still work as intended. I'm treating them more as
hints. I actually spent a fair amount of time trying to figure out a
"config file" format that represented the data I am currently pulling
from the included classes, but I've not been able to come up with
anything that represents the complexity and flexability I need without
requiring a minimal programing language and it seems silly to make
someone learn yet another language to do what seems to work quite well
using the puppet DSL. That's not to say there isn't a better way, I
just haven't come up with something better.
>
> What I'd do to make apache2 selectively removable is a subclass:
>
> class apache2 {
> package { "apache2": ... }
>
> class disable inherits apache2 {
> Package["apache2"] { ensure => absent }
> }
>
> }
>
> Nodes then make sure to not have apache installed by including
> apache2::disable.
>
> As for cross-platform, I try to rely on facter to flesh out the minimum
> of required discrepancies. E.g., I have a class for the at daemon that
> runs on SUSE and Debian systems. Here's how I work around a problem with
> the SUSE init script:
>
> package { "at": ensure => installed; }
> if $operatingsystem != "Debian" { #SUSE
> Service { hasstatus => true }
> }
> service { "atd":
> enable => true,
> ensure => running,
> require=> Package["at"],
> }
>
> In more complex scenarios, it may even make sense to specify further
> subclasses for specific platforms, but I try and avoid that. The point
> is that the module emits a platform-independent interface for installing
> and running atd, so platform-specific subclasses actually hurt. The
> facter-based constructs can become quite entangled in places, but
> they're meant to be "internal magic" so that's usually acceptable.
What you point out his is completely true. I will grant that without
a large number of "package config" class, there is not a lot of value
to my 'software' resource. However, as I continue to use it and
create configs that work on multiple platforms, the number of them
will increase and the amount of work others will have to do to write a
module that is "platform agnostic" will reduce. I think the git.pp,
git-core.pp, and git-daemon.pp classes and the way they work together
is a really good example of how this becomes beneficial. When you
start running situations where it takes multiple packages to provide
the same functionality as a single package on another system, things
get hairy. So far it looks like I've been able to move all the
wackiness into the core 'software' resource with minimal work int the
"package config" classes.
Now that I have the 'defined' syntax correct for classes, my
"software" resource will fall back to behaving just like the package
resource. And because it still does use the package resource on the
back end, it can easily play nicely with existing manifests without
requiring any modifications unless the maintainer decides to convert
everything to the 'software' resource.
One of the things I've found frustrating with puppet is that it
doesn't come packaged with any modules. I suspect that's due to the
fact that truly generic yet useful manifests are difficult to come
by. It's my opinion that if we can reduce the complexity of writing
platform agnostic modules without losing flexibility, we will start to
see modules that are reasonable to include with a base puppet install.
There are a few under the hood enhancements I'm going to add to the
current module and the I will start putting together some decent
documentation and will try to include a good "why would I want to use
this" section. I don't know that I've yet been able to properly
explain the benefits I see in this, but hopefully as I put together
the documentation I'll be able to articulate it more clearly.
Your input (and everybody else's) is greatly appreciated.
>
> HTH,
> Felix
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
