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).
Trevor
On Thu, Dec 8, 2016 at 3:50 AM, Erik Dalén <erik.gustav.da...@gmail.com>
wrote:
>
>
> On Wed, 7 Dec 2016 at 14:54 Trevor Vaughan <tvaug...@onyxpoint.com> 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 puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-dev/CAAAzDLfUzXQ-ZxzhZF2xT3bPFpLUbGMKaX%
> 2BGnWAVvFurkGqs7A%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-dev/CAAAzDLfUzXQ-ZxzhZF2xT3bPFpLUbGMKaX%2BGnWAVvFurkGqs7A%40mail.gmail.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%2BFoVxgMXwnD_rKxRVh5mjwUPkCx0TVg%2Brc4y%3DLVjEUR08WQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
