Digant C Kasundra wrote:
> This is an interesting approach and certainly valid and should work. I'm not
> sure I would use the virtual resources since one could just as easily define
> those things in the classes they are used in. Virtual resources are better
> when you wnat to declare something in one place but it could be realized in
> any number of places (making it impossible to be declared in all of those
> places b/c if two such classes were included, you'd have an error)
>
These resources are virtual to facilitate subclassing the classes
available with the module.
> I think having the OS specific subclasses override the package name instead
> of a large case statement in the initial package declaration is spiffy. I
> can actually seeing both ways being useful. Sometimes, I like to see all the
> various ways a package (or service) might look in one place, so I sometimes
> like to see the case statement approach. Other times, I like to see specific
> changes that are related to an OS or similar logical grouping to be made in
> an appropriate subclass with the use of overrides.
>
I choose operating system specific subclasses because of how these can
override resource parameters, and do not have to be all-inclusive like
some case statements would need to be. I think also inheritance between
the sub-classes is relevant.
> To answer about use-cases, we have in our ssh module some subclasses that are
> relevent to a particular configuration of ssh server. For instance,
> ssh::global allows ssh connections from off campus while our regular ssh
> doesn't. I prefer these as subclasses b/c I like to look at my list of
> classes to glean what kinds of things my server is setup to do (and when I
> build an external node tool, rather than messing with variables and blah blah
> blah, I'll just be adding or dropping classes).
>
This of course is perfectly doable:
// import module ssh
class ssh::server::global {
include ssh::server
}
or in case of needing to override the source;
class ssh::server::global inherits ssh::server {
File["/etc/ssh/sshd_config"] {
source => "puppet:///ssh/something/different"
}
}
I hope this makes sense.
Kind regards,
Jeroen van Meeuwen
-kanarip
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
