On 01/19/2011 11:34 PM, MJ wrote:
>> Interesting construct. Why do you need to go so meta? Usually, instead
>> of building a framework for packages/services/... that you specify in
>> some external scheme that you make up, you just write a classes for each
>> such set in puppet DSL in the first place. Not much more work and much
>> less of a hassle I'd assume.
>
> I've written up a bit about why I'm writting this module at
> https://github.com/therevmj/puppet-module-software/wiki
> To ballpark it fairly quickly, having a common namespace for packages
> regardless of you platform make writing other modules that are cross
> platform compatible easier and more readable, and require less code
> duplication. This comes into play even more when you have to deal
> with multiple providers on a single platform. The amount of code you
> end up writing starts ballooning.
>
> Consider that you have written and apache2 module which installs the
> correct package and are including it in a manifest with:
> include apache2
>
> What happens when you want to remove this package? You might just
> rework the apache to module to remove ensure that it removes the
> packages. But if you are using it somewhere else, you can't do this.
> You could create a separate class that removes apache, but that will
> result in a lot of duplicated code. Maybe this will work:
>
> $apache_ensure = "absent"
> include apache2
>
> but you are stuck writing bits of code determine if you should install
> or remove that package and you are duplicating that code in each of
> your modules.
>
> Ultimately, this seems to me a good way to consilidate the complexity
> of dealing with cross platform compatibility issues and enabling
> others to focus on the more basic bits of what software needs to be
> installed rather than how to do it and what is the package name. It's
> possible I'm overthinking things, but it has made my other modules
> much more straight forward.
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.
First off, don't rely on dynamic scoping (i.e. variables being available
in included classes) if it's at all possible.
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.
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.
