Hi John,
Sorry for the delayed reply.
On 05/06/2013, at 11:51 PM, jcbollinger <john.bollin...@stjude.org> 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+unsubscr...@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.
