Hey Nan and John,
Thank you both for the replies and insight into my questions below; they
are most helpful and very much appreciated.
Based on your answers, I have few other questions that occurred to me:
In response to my question about inherits, John had mentioned this below:
"If you don't need the variables of the params class for class parameter
defaults, however, then you can replace inheritance with 'include'ing (or
'require'ing or 'contain'ing) the params class it the start of erstwhile
child class's body."
In my example config.pp, I'm using things like "$puppet_config_path =
$::puppet::params::puppet_config_path," which obviously points to my
params.pp file and thus would in theory, pull the variable value and
evaluate accordingly. If I am indeed pointing these local variables to my
params.pp, it doesn't seem obvious that I need any include or inhert to
params.pp in my subclasses. In this example, I do indeed need the
variables from my params class for my subclass defaults but because I'm
specifically calling these with the use of local variables, is it advisable
to still "include" the params.pp subclass? It seems that my manifests
would be more tidy if I didn't have include/inherits littered throughout my
subclasses.
Further, if I had a selector or case statement in my params.pp, they it
would seem appropriate to "include" params.pp in my config.pp because I
indeed do need that selector/case statement to be evaluated before the
config.pp subclass can be completed. Am I thinking about this correctly?
Lastly, it seems that in the case of any module with subclasses, I want and
need to include class/subclass ordering or the sake of ordering sanity. In
your opinion, should I be including subclass ordering in my init.pp for
each module I write (assuming it includes subclasses)?
Thank you guys for your invaluable information and for you patience.
Cheers,
Mike
On Friday, September 19, 2014 4:01:28 PM UTC-7, Mike Reed wrote:
>
> Hello all,
>
> I have a question about class and subclass relationships and what is/isn't
> the ideal way to go about such a thing. Please bear with me as I'm still
> refining my understanding of containment. Let's say I have a puppet module
> which manages the install of puppet and has the following pieces (currently
> using puppet v.3.4.3):
>
> *init.pp*
> class puppet {
> # evaluate supporting classes
> include puppet::params
> include puppet::config
> include puppet::service
>
> anchor { 'puppet::begin' : } ->
> class { '::puppet::params' : } ->
> class { '::puppet::config' : } ~>
> class { '::puppet::service' : } ->
> anchor { 'puppet::end' : }
> }
>
> *params.pp*
> class puppet::params {
> # puppet general params
> $puppet_path = '/etc/puppet'
> $puppet_config_template = 'puppet/puppet.conf.erb'
> $puppet_package = 'puppet'
> $puppet_common_package = 'puppet-common'
> $puppet_service_ensure = 'running'
> $puppet_service_enable = true
> $puppet_prod_version = '3.6.2-1puppetlabs1'
> $puppet_dev_version = '3.6.2-1puppetlabs1'
> validate_string($puppet_path)
> validate_string($puppet_config_template)
> validate_string($puppet_package)
> validate_string($puppet_common_package)
> validate_string($puppet_service_ensure)
> validate_bool($puppet_service_enable)
> validate_string($puppet_prod_version)
> validate_string($puppet_dev_version)
> }
>
> *config.pp*
> class puppet::config (
>
> $puppet_config_path = $::puppet::params::puppet_config_path,
> $puppet_config_template = $::puppet::params::puppet_config_template,
> $puppet_service = $::puppet::params::puppet_service,
>
> ) inherits puppet::params {
>
> file { 'puppet.conf' :
> ensure => present,
> path => "${puppet_config_path}/",
> content => template("${puppet_config_template}"),
> notify => Service["${puppet_service}"],
> }
> }
>
> *service.pp*
> class puppet::service (
>
> $puppet_package = $::puppet::params::puppet_package,
> ***truncated variables for sake of a long post***
>
> ) inherits puppet::config {
>
> package { "${puppet_package}":
> ensure => "${puppet_prod_version}",
> }
>
> package { "${puppet_common_package}":
> ensure => "${puppet_prod_version}",
> }
>
> service { "${puppet_service}":
> ensure => "${puppet_service_ensure}",
> name => "${puppet_service}",
> enable => "${puppet_service_enable}",
> hasrestart => true,
> hasstatus => true,
> subscribe => Package["${puppet_config_template}"],
> }
> }
>
> Based on the above, I've left a few things which I feel don't belong but
> for the sake of my questions, they're included.
>
> Per the above init.pp, I've added an anchor to force ordering. My
> understanding is that this has nothing to do with application-order and
> more to do with parse-order. With that said, I have a few questions:
>
> 1. By adding the 'include' in init.pp, my understanding is that simply
> says to 'evaluate' the subclasses but does not indicate an order to which
> subclasses are to be applied. Is that correct?
>
> 2. I think the 'inherits' function is depreciated but should each
> instance be replaced with a 'contain' (based on the order I want)
> throughout my subclass manifests? My understanding is that I should never
> 'contain' more than one subclass within the same module as puppet will be
> confused on ordering.
>
> 3. I rather like the idea of the anchor in the init.pp because I only
> have one place to go to, in order to see the relationship of the
> subclasses. With the introduction of the 'contain' feature, I feel like the
> anchor is no longer needed; however, is there a preferred way of ordering
> these subclasses without using the anchor pattern?
>
> As always, thanks in advance for your help.
>
> Cheers,
>
> Mike
>
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/e979eee0-eafd-4b75-a672-9d5f945716f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
