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.
