Re: [Puppet Users] class/subclass relationship ordering and containment
On Friday, September 19, 2014 7:37:57 PM UTC-5, Nan Liu wrote:
TLDR summary:
>
> 1. include/require class does not provide containment.
> 2. anchor is just a empty resource for containment.
> 3. contain class provides containment without the need for anchor
> 4. contain may cause unnecessary relationship, so use it only when
> appropriate
> 5. The original purpose for inherits, resource parameter override, is
> rarely used. These days it's mostly a hack to have module data. classes
> inherit params class which only contain puppet variables and no resources.
> (I won't get into this and only focus on the previous points)
>
> On Fri, Sep 19, 2014 at 4:01 PM, 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)
>>
>
> validate don't serve any purpose here, since you setting these values to a
> specific value.
>
>
>> }
>>
>> *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:
>>
>
>
> The anchor is not parse-order, it to server as a ghost containment
> resource for the class.
>
I re-emphasize that point. The Anchor pattern has NOTHING to do with parse
/ evaluation order, exactly contrary to the OP's assertion. It is only
relevant to client-side order of resource application.
> The syntax short hand is what confusing. You can totally rewrite as
> following:
>
> class { '::puppet::params' : require => Anchor['puppet::begin']}
> class { '::puppet::config' : } ~>
> class { '::puppet::service' : before => Anchor['puppet::end']}
> anchor { ['puppet::begin', 'puppet::end']: }
>
>
Although that does have exactly the same application-order implications as
the OP's version, it has slightly different evaluation / catalog-building
semantics, owing to the use of resource-like class declarations in place of
'include' / 'require' / 'contain'. That probably does not matter for this
example, but it might matter in some other cases.
> 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 w
Re: [Puppet Users] class/subclass relationship ordering and containment
TLDR summary:
1. include/require class does not provide containment.
2. anchor is just a empty resource for containment.
3. contain class provides containment without the need for anchor
4. contain may cause unnecessary relationship, so use it only when
appropriate
5. The original purpose for inherits, resource parameter override, is
rarely used. These days it's mostly a hack to have module data. classes
inherit params class which only contain puppet variables and no resources.
(I won't get into this and only focus on the previous points)
On Fri, Sep 19, 2014 at 4:01 PM, 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)
>
validate don't serve any purpose here, since you setting these values to a
specific value.
> }
>
> *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:
>
The anchor is not parse-order, it to server as a ghost containment resource
for the class. The syntax short hand is what confusing. You can totally
rewrite as following:
class { '::puppet::params' : require => Anchor['puppet::begin']}
class { '::puppet::config' : } ~>
class { '::puppet::service' : before => Anchor['puppet::end']}
anchor { ['puppet::begin', 'puppet::end']: }
> 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?
>
Mostly.
> 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.
>
The inherits params class data pattern can't be replaced by contain.
contain is a new function that is used to eliminate the need for anchor.
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
[Puppet Users] class/subclass relationship ordering and containment
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/daeb1827-7d94-4921-ae09-31f2ea480e9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
