In terms of the 'after all resources processed' I think this is one of
those cases where you present the capability because there is need and
caveat it with the fact that you may, or may not, have access to resources
that have been modified after the fact.
In theory, with a hook like this, you
On 16/04/18 23:13, Trevor Vaughan wrote:
I thought there were dangers with Virtual Resource being accidentally
realized sometimes?
Not without users doing something bad (like realizing all) - puppet
itself does not realize virtual resources willy-nilly.
We found a super-hacky way to call
I thought there were dangers with Virtual Resource being accidentally
realized sometimes?
We found a super-hacky way to call functions at the end of a compile which
we use in
https://github.com/simp/pupmod-simp-compliance_markup/blob/master/manifests/map.pp.
It would be *really nice* if there
On 16/04/18 17:38, Trevor Vaughan wrote:
How difficult would it be to create a third type of resource which is an
'ephemeral resource' whose only purpose is data collection on a host to
be used by some other collector?
These items would not be part of the catalog or added to the graph but
In terms of #2, there's actually a ticket that I put in a while ago for a
shared data cache.
But, I recently realized that the common pattern is to literally map every
line in a file as a separate resource. We've had the same issue with
firewall rules, etc... for quite some time. So, the most
On Monday, April 16, 2018 at 10:38:55 AM UTC-5, Trevor Vaughan wrote:
>
> How difficult would it be to create a third type of resource which is an
> 'ephemeral resource' whose only purpose is data collection on a host to be
> used by some other collector?
>
> These items would not be part of
On Wednesday, December 7, 2016 at 7:54:44 AM UTC-6, Trevor Vaughan wrote:
>
> I was looking through the puppetlabs-concat module as well as some of my
> modules that have aggregation functionality and I realized that the catalog
> really shouldn't be sending the intermediary resources to the
