On Thu, Dec 8, 2016 at 7:28 AM, Trevor Vaughan <tvaug...@onyxpoint.com> 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 <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.
>>
>> 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.
--
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/CAHTHiAE6WauMyaLY6V6sJhS%2ByhKNZBF-2Bc2HMNbk0SWpH_Oiw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
