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 "user obvious" thing to do is to let everyone keep throwing resources everywhere but be able to mark them explicitly as being 'lightweight' or 'ephemeral' or somesuch. This was really solidified for me when I started passing around hashes to be able to collapse my augeas command into a single run. I thought about it and realized that's a LOT of work to get around limitations in the abstraction realization. Trevor On Mon, Apr 16, 2018 at 2:19 PM, John Bollinger <john.bollin...@stjude.org> wrote: > > > 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 the catalog or added to the graph but >> would instead just hang around for reference during compilation. >> >> This would fix the catalog explosion issue when you start doing exported >> resources based on large numbers of things and/or things like firewall >> rules and copious file_line resources. >> >> Basically, a 'data' -> 'collector' pattern where you can >> optimize...well...everything into a MUCH smaller catalog that is sent to >> the client for processing. >> >> > I can't speak to how difficult such a thing might be to implement, but > inasmuch as I take the idea to be that the ephemeral resources could serve > as input data for constructing a smaller number of ordinary resources, I > suggest two additional approaches that could be considered: > > 1. Provide a convenient mechanism for directing (ordinary) collected or > declared resources to a different aggregate than the target node's > catalog. One could use such a mechanism to divert resources of any type > away from the catalog, so no new flavor of resource would be required. > This supposes that the data associated with such resources would still be > available during catalog building, to inform declaration of resources that > do go into the catalog. > > 2. If the need is for a repository of dynamic node data, and especially > if those data are expected to often not correlate directly to target-node > resources, then sit down and design that thing from the ground up. > > > 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/6d665f35-9a86-4f9a-a256-a4fc443811cb%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/6d665f35-9a86-4f9a-a256-a4fc443811cb%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoWnckqzJ9DdUZzrELVJSJX%2BvSp6F2SJ4F3Jwuk-_ubNhQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
