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

>> This seems a bit backwards to me, for all other parts of the query you
>> just leave it out if you don't want to match on it. There's no need for a
>> explicit tags=='*' if you want to match on all tags for example. So I don't
>> see why environment matching would work the opposite way.
>>
>> So I'm proposing instead that you add environment==$::environment to your
>> query if you want to collect only from your current environment.

How would you do this with 3rd party modules though? Modify them?

We need to be wary of people who do just want real separation, no one
has chimed in formally yet about this yet (this conversation has been
mainly on puppet-dev).

ken.

-- 
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/CAE4bNTn%2B1cmhfLU1TqFcdDkFeX4htfz%3DG71RghxQk46Uk4qnyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to