On Friday, September 7, 2012 10:02:56 AM UTC-5, Jakov Sosic wrote:
>
> On 09/07/2012 03:20 PM, jcbollinger wrote:
>
> > That's what I addressed at the end of my previous message. I strongly
> > recommend that you look into hiera. Adding to what I already said,
> > however, resources of defined types are just fine when a resource (as
> > opposed to a class) is in fact what you want. It is worthwhile to
> > understand the difference between class and resource at the conceptual
> > level, because there are some circumstances that require a class. You
> > may save yourself future grief if you start out with classes where
> > they're appropriate, even if, for the moment, they're not actually
> needed.
>
> I don't think you understood me there :) I use hiera for some purposes,
> but this is my class:
>
> class cobbler (
> $service_name = $cobbler::params::service_name,
> $package_name = $cobbler::params::package_name,
> $package_ensure = $cobbler::params::package_ensure,
> $distro_path = $cobbler::params::distro_path,
> ) inherits cobbler::params {
> package { $package_name :
> ensure => $package_ensure,
> }
> service { $service_name :
> ensure => running,
> enable => true,
> require => Package[$package_name],
> }
> file { $distro_path :
> ensure => directory,
> owner => root,
> group => root,
> mode => '0755',
> }
> file { '/etc/cobbler/settings':
> ensure => present,
> owner => root,
> group => root,
> mode => '0644',
> content => template('cobbler/settings.erb'),
> notify => Service["$service_name"],
> }
> define add_distro ($arch,$isolink){
> $distro = $title
> cobblerdistro { $distro :
> ensure => present,
> arch => $arch,
> isolink => $isolink,
> destdir => $cobbler::distro_path,
> require => Service[$cobbler::service_name],
> }
> }
> define del_distro (){
> $distro = $title
> cobblerdistro { $distro :
> ensure => absent,
> destdir => $cobbler::distro_path,
> require => Service[$cobbler::service_name],
> }
> }
> }
>
>
> So, from node manifest, I can do this:
> node 'mynode' {
> class { 'cobbler':
> distro_path => '/data/distro'
> }
> cobbler::add_distro { 'CentOS-6.3-x86_64':
> arch => 'x86_64',
> isolink =>
> '
> http://mi.mirror.garr.it/mirrors/CentOS/6.3/isos/x86_64/CentOS-6.3-x86_64-bin-DVD1.iso',
>
>
> }
> cobbler::add_distro { 'CentOS-6.2-x86_64':
> arch => 'x86_64',
> isolink =>
> '
> http://mi.mirror.garr.it/mirrors/CentOS/6.2/isos/x86_64/CentOS-6.2-x86_64-bin-DVD1.iso',
>
>
> }
> }
>
>
> Is this OK?
>
It depends on what you mean by "OK". Your class is not consistent with my
recommendations, but that doesn't make it wrong.
I am recommending that you use *only* hiera to communicate site- and
node-specific data to your classes. That is, according to me, you should
avoid use of parametrized classes wherever it is feasible to do so. That
would mean using parametrized classes only from third-party modules,
really, since you can always avoid parametrization in classes you write
yourself. Thus, your "cobbler" class might start this way:
class cobbler {
include 'cobbler::params'
$service_name = hiera('cobbler_service_name',
$cobbler::params::service_name)
$package_name = hiera('cobbler_package_name',
$cobbler::params::package_name)
$package_ensure = hiera('cobbler_package_ensure',
$cobbler::params::package_ensure)
$distro_path = hiera('cobbler_distro_path', $cobbler::params::distro_path)
# ...
Voila, (the beginning of) a non-parametrized version of your class.
Nothing else has to change (but see below). Note that the non-parametrized
version also doesn't need the inheritance trick; it uses an ordinary
'include' instead.
On a separate note, the PuppetLabs style recommendation and prevailing
opinion agree that type definitions should go into their own files. Thus,
instead of add_distro() and del_distro() being defined in the body of class
cobbler, they should appear in sibling files add_distro.pp and
del_distro.pp. And as a side note, that will actually be much cleaner with
the non-parametrized version of class cobbler than it would be with the
parametrized version, because
1. It is safe for the definition bodies (in a separate file) to refer to
class variables, but not to class parameters (the latter fails in some
Puppet versions).
2. The definition bodies can 'include' class cobbler to ensure that its
variables are recognized (which they must not do if 'cobbler' is
parametrized, even if they know the correct parameters, because
parametrized classes can be declared at most once)
3. If you do (2), then, at your option, your nodes don't have to declare
class 'cobbler' at all as long as they declare at least one
cobbler::add_distro or cobbler::del_distro resource
So, for instance:
modules/cobbler/manifests/add_distro.pp:
define add_distro ($arch, $isolink) {
include 'cobbler'
cobblerdistro { $title :
ensure => present,
arch => $arch,
isolink => $isolink,
destdir => $cobbler::distro_path,
require => Service[$cobbler::service_name],
}
}
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/z_FI9FiOJVMJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
