Order of removal of resources

[Peter Faller]

What is the effect of the 'require' metaparameter when ensure is set to absent, i.e. when a resource

is removed? It seems that changes to the required resource are applied before changes to the requiring

resource are applied - is that always the case?

When one resource (R1) depends on another resource (R2) to be able to be created, having R1::require=>R2 works as expected - R2 is created first, then R1. (My case is where R2 is a configuration file that has to be present for R1 to be created). But now in my case, R2 has to be present for R1 to be removed as well. Having R1::require=>R2 and both R1::ensure=>absent and R2::ensure=>absent results in R2 being removed before R1 is removed; where I am trying to get R1 removed before R2 is removed.

Is this possible to achieve with Puppet?

Here's a simple test that I put together:

class test ($ensure) {

  file {'test1':

    path => '/tmp/test1',

    content => 'test1',

    ensure => $ensure,

    #require => File['test0']

  }

}

class outer ($ensure) {

  file {'test0':

    path => '/tmp/test0',

    content => 'test0',

    ensure => $ensure,

    #

  }

  class { 'test':

    ensure => $ensure,

  }

}

class {'outer':

  ensure => present,

  #ensure => absent,

}

Comment out the 'require => File['test0'], change outer::ensure => present:

Notice: /Stage[main]/Test/File[test1]/ensure: created

Notice: /Stage[main]/Outer/File[test0]/ensure: created

Notice: Finished catalog run in 0.19 seconds

This sequence is as expected.

Change outer::ensure => absent:

Notice: /Stage[main]/Test/File[test1]/ensure: removed

Notice: /Stage[main]/Outer/File[test0]/ensure: removed

Notice: Finished catalog run in 0.26 seconds

This sequence is also as expected, but I don't think there will be a guaranteed order of execution.

Uncomment 'require => File['test0'] and outer::ensure => present:

Notice: /Stage[main]/Outer/File[test0]/ensure: created

Notice: /Stage[main]/Test/File[test1]/ensure: created

Notice: Finished catalog run in 0.19 seconds

Also as expected.

Change outer::ensure => absent:

Notice: /Stage[main]/Outer/File[test0]/ensure: removed

Notice: /Stage[main]/Test/File[test1]/ensure: removed

Notice: Finished catalog run in 0.22 seconds

This is not the desired sequence - I want to get test1 removed first. Any way to do that?

[Craig Dunn]

On Wed, Sep 21, 2016 at 9:33 AM, Peter Faller <pgfa...@gmail.com> wrote:

What is the effect of the 'require' metaparameter when ensure is set to absent, i.e. when a resource

is removed? It seems that changes to the required resource are applied before changes to the requiring

resource are applied - is that always the case?

When one resource (R1) depends on another resource (R2) to be able to be created, having R1::require=>R2 works as expected - R2 is created first, then R1. (My case is where R2 is a configuration file that has to be present for R1 to be created). But now in my case, R2 has to be present for R1 to be removed as well. Having R1::require=>R2 and both R1::ensure=>absent and R2::ensure=>absent results in R2 being removed before R1 is removed; where I am trying to get R1 removed before R2 is removed.

The require merely implies that R2 should be "managed" before R1, and "managed" being setting the desired state (absent, present...etc) so the actual value of ensure is unimportant here.

If you want to change your requirements based on the value of ensure you could do something like....

if $ensure == 'present' {

  Resource['one'] -> Resource['two']

elsif $ensure == 'absent'

  Resource['two'] -> Resource['one']

}

Regards

Craig

[Peter Faller]

Thanks Craig - that does work, but what it says in the documentation is true:

"Note: Chained collectors can potentially cause huge dependency cycles and should be used carefully."

This approach works fine for 'leaf' resources; but when the dependencies get more complicated it is very easy to create dependency cycles. It's beginning to look to me that Puppet is best suited to cases where resources once added, remain in place.

[Rob Nelson]

The dependency warning may be overstated a bit, in your situation you're not likely to cause that issue by accident.

Another view might be that systems should be built from scratch when significant changes are made. Regardless of your CM tool, that's generally a better idea these days - even upgrades generally benefit from standing up a fresh system to replace the older system.

Also, order of removal of files does seem odd, if neither is required. Was that a contrived example or an actual example? If the latter, that seems like a really badly behaved application, from the outside.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/dc9d3590-bdec-4b0b-b360-20afcd97f15f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Rob Nelson
rnel...@gmail.com

[Peter Faller]

That was a contrived, simplified example. The real situation is much more complicated.