On Thu, Dec 8, 2016 at 7:28 AM, Trevor Vaughan <[email protected]> wrote: > So, in theory, ephemeral resources would only have relationships on items > that need them for data and/or building purposes. > > We already have this problem and, as more items start getting managed, we're > going to run into more issues with large catalog compile and application > death. > > I guess they could be called shared_data objects or something like that. > They would be declared the same way as resources but perhaps a metaparameter > could be added that marks them as data. > > I was kind of thinking: > > fragment { 'part1': > item_type => 'ephemerai' (or data, or something), > .... > } > > This would mark it to be placed in the system in a location that will never > make it into the live catalog because it's irrelevant to the application of > the catalog itself. > > Actually, looking at the catalogs, there may be quite a bit of information > that is irrelevant to the clients in general and could be split into a > reporting/metadata bundle in case there is an error. If there's no issue, > you don't need any of this information at all. If you run in debug mode (and > you know that at instantation time, you need all of it).
It sounds like what we're discussing here might be more effectively enabled using something like the Builder pattern: https://en.wikipedia.org/wiki/Builder_pattern As I understand, the main use case we're discussing is essentially "I want to construct a resource by building it up from component pieces". Really, what we want here is to be able to define components or properties of a resource separately, which the type can later use to construct the actual resource that will end up in the catalog. This might look something like: concat { '/etc/foo.conf': ensure => present, # ... } Concat['/etc/foo.conf'].add_fragment({ content => '[foo]', priority => 0, } Concat['/etc/foo.conf'].add_fragment({ content => 'bar = true', priority => 20, }) Concat['/etc/foo.conf'].add_fragment({ content => 'baz = "bat"', priority => 10, } > Trevor > > On Thu, Dec 8, 2016 at 3:50 AM, Erik Dalén <[email protected]> > wrote: >> >> >> >> On Wed, 7 Dec 2016 at 14:54 Trevor Vaughan <[email protected]> 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 client. >>> >>> While I'm not positive, the ability to mark resources as ephemeral >>> *might* go a long way toward solving the 10k+ resources issue. >>> >>> The idea is that only the final 'aggregation' resource would be present >>> in the catalog and all other resources would be removed right after they are >>> processed. >>> >>> The main issue that I see with this is in debugging. However, I think >>> this is pretty much the case with concat presently so I don't know that it >>> changes much. >>> >>> Thoughts? >> >> >> Another issue would be resource relationships on ephemeral resources. They >> might not be that common on concat_fragment, but on anchor it is pretty >> common to use them. >> >> Also I think some benchmarking how much they actually slow down things >> would be good. And checking if there is anything that can be optimized when >> applying resources that do nothing. >> >> /Erik >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/CAAAzDLfUzXQ-ZxzhZF2xT3bPFpLUbGMKaX%2BGnWAVvFurkGqs7A%40mail.gmail.com. >> >> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoVxgMXwnD_rKxRVh5mjwUPkCx0TVg%2Brc4y%3DLVjEUR08WQ%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAHTHiAE6WauMyaLY6V6sJhS%2ByhKNZBF-2Bc2HMNbk0SWpH_Oiw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
