Nigel,
Just so we understand the requirements of this - what would it take to make
a function that
is usable in way that a few of us have mentioned - something that lets us
say "If a class
is included in this host, then X". It seems like this would be desirable
functionality and so
far everything I've heard has been a clumsy workaround for this base kind
of functionality.
What I don't understand is why defined creates a parse order dependency and
why it's not
able to search through the entire catalog to see if the class is defined.
This is totally my
lack of understanding of the code shining through but what stops this being
possible?
Is it just the case that you don't want to rely on a class in the future
has hasn't yet been
processed because it might fail and therefore, for the purposes of puppet,
not be defined?
On Mon, Jan 23, 2012 at 7:57 PM, Nigel Kersten <ni...@puppetlabs.com> wrote:
>
>
> On Mon, Jan 23, 2012 at 5:15 AM, Felix Frank <
> felix.fr...@alumni.tu-berlin.de> wrote:
>
>> Hi,
>>
>> On 01/20/2012 11:34 PM, Cody wrote:
>> > Defining all somewhat common packages in a central location becomes
>> > unrealistic when you no longer "control" the code that is in every
>> > module you use. If you obtain five modules from the forge and they
>> > all require a specific package and so all define that package your not
>> > going to convince, nor is it a good design to require everyone to move
>> > the package definitions from that collection of modules. They need to
>> > function as a collection out of the box.
>>
>> Agreed. How can this be accomplished?
>>
>
> Felix, could you take this to a new thread please? I'd really like to keep
> this one focused on the topic at hand if possible :)
>
>
>
>>
>> Perhaps there needs to be some kind of "Forge common" module that by
>> policy can only ever declare virtual resources (packages are a prominent
>> example).
>> A user who wishes to retain the capability of using modules from the
>> Forge would be required to install this common module, and replace their
>> own resource declarations with realizations of the common resources.
>> For this to work, it's definitely a plus that you can override
>> attributes in collections:
>> Package<| title == "apache2": |> { ensure => "2.2.12" }
>> ...although that does bear some caveats. Does this still work in recent
>> versions?
>>
>> If we can take this for granted, all Forge modules can adhere to that
>> same standard.
>>
>> Yes, it's quite a hassle.
>>
>> No, I didn't think this through very thoroughly ;-)
>>
>> Just another pair of cents.
>>
>> Cheers,
>> Felix
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>>
>
>
> --
> Nigel Kersten
> Product Manager, Puppet Labs
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
