On Wed, Jan 25, 2012 at 9:59 AM, Ashley Penney <apen...@gmail.com> wrote:
> I don't have a solution but I do want to chime in and state that modules
> that
> exist just to collect together virtual resources is a horrible thing.
> We're just
> talking about working around the way Puppet works right now rather than
> defining what the end solution should be.
>
Absolutely right Ashley.
Please lets focus the conversation here on how things *should* be.
>
> I would be happiest with some kind of thing that can handle multiple
> versions
> of the same resource and work out a way to apply them as one entry. Like
> others suggested something that can merge all the unique attributes
> together
> for one entry. After all, if they've been included on the host all of
> those attributes
> should apply so I can't see a dangerous downside to this.
>
> It has to be better than trying to organize things so you only use a
> resource
> once and having all kinds of tricks and complicated workarounds. I don't
> want
> my modules to have to rely on some weird generic module full of virtual
> resources
> just to use a package without clashing into a module written by a
> coworker. I
> think modules should be capable, if possible, of standing alone, and this
> is ruining
> that basic concept.
>
> On Wed, Jan 25, 2012 at 12:12 PM, Dan Bode <d...@puppetlabs.com> wrote:
>
>>
>>
>> On Tue, Jan 24, 2012 at 1:28 AM, Felix Frank <
>> felix.fr...@alumni.tu-berlin.de> wrote:
>>
>>> Hi,
>>>
>>> there was a discussion in the "can we deprecate defined() in Telly"
>>> thread about how we can even begin to design Forge modules without it.
>>>
>>> A recurring problem is that multiple modules rely on certain packages,
>>> and there is no good model (yet) to unite their resource declarations.
>>> Therefore it's a common (although imho disgusting) workaround to do
>>> things like
>>> if !defined(Package[foo]) { package { "foo": ensure => installed } }
>>>
>>> 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?
>>>
>>> Perhaps there needs to be some kind of "Forge common" module that by
>>> policy can only ever declare virtual resources (packages are a prominent
>>>
>>
>> Until there is a way to distinguish between collection of regular versus
>> virtual resources, I hope that we don't do anything that advocates the
>> usage of virtual resources.
>>
>> The problem is that collections (like below) meant to
>> establish multiple dependencies unfortunately have the side effect of
>> realizing virtual resources.
>>
>> Class['apt'] -> Package<| |>
>>
>>
>>> 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.
>>>
>>> This is a rough sketch of how things might possibly work, and surely has
>>> lots of wrinkles of its own. Still, I'm quite sure we need a proper way
>>> to rid ourselves of the horror that is the parse order dependent check
>>> for defined resources ;-)
>>>
>>> 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.
>>>
>>>
>> --
>> 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.
>
--
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.
