On Wednesday, August 22, 2012 5:06:41 PM UTC-4, Ramin K wrote:
>
> 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. :-)
I'm positive that this is the case. lol. But really, a big part of it is
that I just
want class definitions to be easy to read, audit, and maintain, and if I
have to
maintain a list of all packages in multiple places, that's going to break
on a
live network. People are people. Someone's going to forget something. The
lists are going to get out of sync. Things will break. It'll be a mess.
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.
>
Yeah, my Samba module is well over 100 lines long and does some pretty nifty
things. I'm sure there will be other packages which will similarly require
special
care and feeding. However, I'd expect the bulk of my packages to simply
need
to be itemized in someway. No special care and feeding required.
> 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.
>
Exactly! I want to build classes to be used as building blocks. I don't
want to have to deal with unexpected package collisions between two
classes because the authors of the two classes didn't know the package
was being used by the other. That's ultimately where this discussion came
from. If a package needs a whole class wrapped around it, it should get
one,
but if it "just needs to be present", then it shouldn't be required, IMHO.
> 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, }
> }
>
Exactly! I want to build classes to be used as building blocks. I don't
want to have to deal with unexpected package collisions between two
classes because the authors of the two classes didn't know the package
was being used by the other. That's ultimately where this discussion came
from. If a package needs a whole class wrapped around it, it should get
one,
but if it "just needs to be present", then it shouldn't be required, IMHO.
One question though…I don't really understand what the $vpackages::params
stuff does. Is there some puppet magic going on there?
thanks,
Michael
--
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/-/zjOe_se8lpYJ.
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.
