Hi John,

Thanks for the reply.
On 05/06/2013, at 12:33 AM, jcbollinger wrote:
On Tuesday, June 4, 2013 1:22:08 AM UTC-5, Tom Lanyon wrote:
I'm testing a 'cleanup' stage which runs after Stage[main] and removes a bunch of package resources.

To do this, I tried a simple check of defined(Package[<foo>]) combined with a custom facter fact (called 'app_packages'):
class app::package::cleaner {

define check_and_remove {
if !defined(Package[$title]) {
package { $title:
ensure => absent

$apps = split($::app_packages, ',')
check_and_remove { $apps: }


node 'foo' {
class { 'app::package::cleaner': stage => 'cleanup' }
Unfortunately, this results in a dependency cycle. It appears that putting the Package[$title] resource reference in defined() actually invokes an implicit dependency between my cleanup helper resource in the cleanup stage and the original Package resource in the main stage.
Augeas[redacted] => Service[iptables] => Class[Iptables] => Stage[main] => Stage[cleanup] => Class[App::Package::Cleaner] => App::Package::Cleaner::Check_and_remove[package-434] => Package[package-434] => Exec[app-graceful-restart] => Class[App] => Stage[main]
Does it do that when Package[package-434] is already declared elsewhere, or only when it is not?
Sorry, I should have been clearer that this occurs when Package[package-434] IS declared elsewhere. "!defined(Package[package-434])" therefore is false, so just by referencing the existing declaration within the defined() call it seems to incite an implicit dependency.

Is this implicit dependency expected behaviour or am I doing something Bad(tm)?

Supposing that the target package is not declared elsewhere (so that the !defined() condition is true) the definition will declare the package itself to ensure it absent, and in that case you would expect a relationship between the defined-type instance and the resource declared by it. If elsewhere you have specific references to that package, applicable resource parameter defaults, or collectors that will match that package, then you can get relationships with it that are not evident from the defined type body.

On the other hand, defined() is evil. Do not use it. Ever.
I had this discussion with someone on #puppet IRC earlier and they ended up with "Oh, in your case, defined() is probably actually what you want."
I usually attribute its malignancy to the parse-order dependency it inherently creates -- which is indeed a serious problem -- but in this case I think trying to use it to approach your problem it has also obfuscated your manifests enough to confuse you about the scope and nature of some of your other declarations.

Instead of using defined(), you can apply logic farther upstream to make the correct declaration in the first (one) place or to apply resource parameter overrides to the correct resources. Alternatively, you can simply determine by other means what packages need to be ensured absent, such as by filtering a list of possible packages against a list of packages that are supposed to be installed. Some of those options may still susceptible to the problem you observed, however, if relevant relationships spring from declarations elsewhere, as I described they may do.
I've tried this other ways, but here's an example of why farther upstream logic doesn't work:

define myapp ($requested_package){

   package { $requested_package:
     ensure => present

   define package_cleanup {
     $installed_package = $title

     if $installed_package != $requested_package {
       package { $installed_package:
         ensure => purged

   # assuming a facter fact named 'installed_packages'
   package_cleanup { split($::installed_packages, ','): }

# now in the case of:
# $::installed_packages = 'one,two,three'
# with:
myapp { 'oneA': requested_package => 'one' }
myapp { 'twoA': requested_package => 'two' }
myapp { 'oneB': requested_package => 'one' }

# we'd end up with package conflicts because
# Myapp[oneA] will define Package[one] (present)
# then define Package[two], Package[three] (absent),
# and Myapp[twoA] will try and define Package[two]
# (present) and fail with a non-uniqueness error.

I don't see how this is doable without defined() or some other check of the catalog to see what packages are "needed" elsewhere. Do you have any suggestions?

For the record, however, no order-of-application relationship should be implied by the reference itself. Therefore, when the referenced Package is declared elsewhere (so that the !defined() condition is false), there should be a relationship between App::Package::Cleaner::Check_and_remove[foo] and Package[foo] only if that relationship is declared somewhere else.
I'd hoped that using a Stage to run after everything else would sort this all out, but I'm now not sure this is correct and also see your earlier post about never using stages [with this and "defined() is evil", which pieces of Puppet /can/ we use safely?].


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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 9 | next ›
Discussion Overview
grouppuppet-users @
postedJun 4, '13 at 6:23a
activeJun 14, '13 at 2:28p

2 users in discussion

Jcbollinger: 5 posts Tom Lanyon: 4 posts



site design / logo © 2022 Grokbase