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