On 2014-04-01 15:59, Ken Barber wrote:
I... kinda like that suggestion. I would keep current behaviour
intact, so
collection would work 'as expected though weirdly' and not break
current
manifests. People who are up to date on this can explicitly select
an
environment to collect.
I also think that this approach works better for community modules.
What if
your module ships with it's own native type and you want to collect
on
those? If you need to explicitly pass an environment for collection
to even
work, what do you pass, 'production' and hope that everyone works
from that
environment?
This is a good point regarding "How do we expect environment
searchability to be applicable in modules?" This kind of feels like
the concept of baking in stages into modules. While on the surface
this might seem neat, does this create assumptions about how you
build
out your environments into a module?
In the modules I remember writing, I've always used tags and naked tag
queries to export/collect resources specific to the module's function.
The most complex setup is this munin module, which uses double
indirection through a class parameter to get to the actual tag value:
https://github.com/DavidS/puppet-munin/blob/master/manifests/init.pp#L556
->
https://github.com/DavidS/puppet-munin/blob/master/manifests/init.pp#L381
->
https://github.com/DavidS/puppet-munin/blob/master/manifests/init.pp#L16
and
https://github.com/DavidS/puppi/blob/master/lib/puppet/parser/functions/get_magicvar.rb
Having to consider environments here too, would be annoyingly complex.
See also my other mail.
Regards, David
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/ef46434d2da2d52bf60a96e0d42aaa6a%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.
