FAQ
Hi John,

Sorry for the delayed reply.
On 05/06/2013, at 11:51 PM, jcbollinger wrote:

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.
If that's really what's happening then you should be able to create a simple test case that demonstrates it. That would be a worthy subject for a bug report.
I'll see what I can do.
Is this implicit dependency expected behaviour or am I doing something Bad(tm)?
Both.

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."
No. defined() is never what you want. It may at times seem expedient, but it's bad news every time.
OK, understood.
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, ','): }
}
I don't much like that general approach in the first place on account of the $requested_package parameter. That you encounter difficulty when you try something a bit dodgy should not be surprising.
Can you explain this further so I can understand the issue?


In fact, despite my dissatisfaction with your approach, you can indeed do this without defined(), and without even disrupting your current structure very much. Here's one way I think would work:

# This class ensures all known app packages are
# by default purged
class app::packages {
$apps = split($::app_packages, ',')
package { $apps:
ensure => 'purged'
}
}

# Overrides the requested package to be declared
# present instead of purged.
define app::myapp($requested_package) {
include 'app::packages'
Package<| title == $requested_package |> {
ensure => 'present'
}
}

# no separate package_cleanup required

OK, I wondered whether we could do something like this however - forgive my naivety - I still can't see how this could be a complete solution without something like defined().

As an example... your above snippet works fine to ensure already installed packages remain installed, but what if we wanted to install a brand new version of app::myapp? Because a 'package' resource with title $requested_package does not yet exist, the Package<||> collector matches no resources and the new package is not installed. The only solution that I can come up with is to check whether such a resource is already defined and, if not, define one.

Your guidance is appreciated.

Tom

--
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

Previous

Follow ups

Related Discussions

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

2 users in discussion

Jcbollinger: 5 posts Tom Lanyon: 4 posts

People

Translate

site design / logo © 2022 Grokbase