On 8/22/2012 9:55 AM, lamour wrote:
So, my basic issue with both the class method and the virtual resources
method is that they basically require me to maintain a SECOND list of
every package I want to maintain this way (either class or virtual
resource definitions). This seems like a lot of syntactic and
logistical overhead, especially when you consider that if we ignore the
possibility of collisions, we can just do this:
package { ['perl', 'mysql', 'gcc', 'screen', 'foo', 'bar', 'baz']:
ensure => installed
}
This is clean, concise, and trivial to understand. This is kind of what
I was hoping for. I understand that we'll probably have to use the
class method for any packages where ACTUAL conflicts exist (e.g., the
version example you gave above), but for virtually all of our packages,
we're not going to have that problem
I'd argue that you're trying to bring your procedural shell scripting
world into Puppet. :-) It's the difference between wanting to
micromanage the control you have of a system vs giving Puppet the power
to affect the control you want. Let's consider some of the packages
you've listed above.
My Mysql module and templates are 200 lines which install and configure
mysql-server, supports three distros, sets various variables based on
local facts, and uses Hiera to manage other settings based on the role
of the server. Installing the package is actually the simplest thing it
does.
In the case of gcc it's part of a modules called general_devel which
installs gcc, make, zlib, etc. I don't recall a situation where I would
need to install gcc without support packages so again installing gcc is
the simplest thing it does. Supports three distros, 30 lines.
Screen is part of the base node and I use a vpackage module and realize
it along with vim, htop, etc. Perl is installed by default so I don't
have it anywhere, but I'd probably put it here or make a module for it
so I could install any support tools and libs there.
So your example in my world ends up looking like the following code. On
the surface it's more complicated, but in application to a node it's
actually simpler in my opinion because I have easy entry points to the
complexity I've delegated to the modules. This allows me to drop
discrete packages of capabilities on to servers without having to
revisit the internal logic every time. include mysql does this for me,
package { 'mysql': ensure => present,} does not.
Ramin
node 'some.node.my.domain.com inherits basenode {
include mysql
include general_devel
realize Package['mysql-client']
}
node basenode {
include sudo
include vpackage
# realize all packages with this tag
Package<| tag = 'utils' |>
}
class vpackage {
# packages with tag => util get realized on all systems
@package { 'curl': tag => 'utils',}
@package { 'htop': tag => 'utils',}
@package { 'lynx': tag => 'utils',}
@package { 'screen': tag => 'utils',}
@package { 'strace': tag => 'utils',}
@package { 'tcpdump': tag => 'utils',}
@package { 'wget': tag => 'utils',}
@package { 'whois': tag => 'utils', name =>
$vpackages::params::whois, }
@package { 'mysql-client': name => $vpackages::params::mysqlclient, }
}
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
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.
