On Sunday, March 30, 2014 9:53:39 PM UTC-5, Ken Barber wrote:
>
> >> I'm all for only collection from the environment you're from but there
> needs
> >> to be a way to override this. No matter the environment I still want
> all my
> >> machines monitored by my Nagios instance which happens to be running on
> the
> >> production environment.
> >
> > I concur with the sentiments and I think the crowd has spoken. I'm
> > pretty sure we'll just add a configuration option for this.
>
> Further to this, I'd say there is a need to add an environment ==
> clause during collection as well, so that the language provides an
> ability to do something finer grained. Its out of scope for our work
> no doubt, probably more of a future PUP ticket or armature.
>
>
Coarser grained too, perhaps? That is, for the case where puppetdb is
configured with collection_environments = 'same', does it not make sense to
support, say,
Nagios_host<<| environment == * |>>
to collect resources from all environments? Or maybe the smoothest path
would be to keep the default behavior of collecting from every environment,
but support an 'environment' key in collectors by which to narrow that to a
single environment. That would retain current behavior for all current
code.
Upon reflection, I think it would be wise to control which resources are
collected strictly via search expressions. I disfavor a configuration
setting affecting that, because if there were one then it would be likely
that different modules would be developed with different assumptions about
the configured behavior. Or to put it a different way, people should not
need to refer to Puppet's configuration to determine what any given snippet
of DSL code means.
Do consider also that either form of search expression involving
'environment' represents a non-trivial change in search scope. Currently,
search expressions consider only attributes of candidate resources, whereas
environment is an attribute of the *node* on behalf of which the resource
is exported. That's by no means an inherent problem, but it does open the
door to requests for other collection behaviors based on the
characteristics of the exporting node. (First will be collection by
exporting node identity, then by nodes declaring certain classes or
resources, then ....) Be ready.
John
--
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/a7af1771-9665-4ddf-980d-26c1ad887e3a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
