Hi Felix, Yes, you definitely got the point.
Unfortunately, clean prefetching is just hard when you're modifying what you want to prefetch. This is why I chose to wait for the catalog to figure itself out and then just delve the catalog for whatever I needed. I've used this pattern a few times with very good results. The only issue is that, since things are happening in the last resource applied, it's not entirely clean in terms of user output. For instance, if you have 15 resources, you'll only see something happen on the last resource for the purge. Having a separate resource that does the same thing is technically cleaner but gets irritating to maintain since you either have to inject it into the catalog in the 'initialize' routine of your other types (just wrap it in a catalog check) or have the user add it explicitly to their manifests if you want them to pass options. Thanks, Trevor On Sun, Jan 5, 2014 at 12:48 PM, Felix Frank < [email protected]> wrote: > Hi, > > On 01/04/2014 10:15 PM, Jeff Bachtel wrote: > > Felix, > > > > Given the constraint to not delete keys from the file until all > > managed keys are instantiated, how about using concat_fragment to > > generate the authorized_keys file in the case of purge management? My > > understanding is that this will change the file atomically > > (eliminating the empty file problem in the PUP). > > > > Apologies if that's far behind where you're at now, > > > > Jeff > > so, I guess that would imply creating an alternate provider? > > I have mixed feelings about the general idea. The ParsedFile base class > poses some limitations, but it allows the management of all properties > of each key rather elegantly... > > On 01/05/2014 02:50 AM, Trevor Vaughan wrote: > > You could also have two custom types, one that creates keys and one > > that purges. The ones that create/manage, can be autorequired by the > > one that purges. > > Interesting. So the ssh_authorized_key resources would do nothing apart > from each generating two resources of these custom types? > > I can't really visualize this yet, but I'm afraid this may suffer from > the same limitation that the current implementation is facing. The hard > part about purging appears to be the need to know the targets at > prefetch time. > > The custom types would likely rely on the existing provider to do their > work? > > > Alternatively, you can use 'flush' to only purge when the last key > > management type is executed on the system. > > > > It's a bit cumbersome, but the general idea can be found > > at > https://www.onyxpoint.com/storing-puppet-provider-metadata-for-single-instance-application/ > . > > Ooh, fascinating read. > > I believe that ParsedFile already behaves in a somewhat similar fashion, > although the design is not as refined as you propose in the post. It > implements a .flush method as opposed to a clever #flush. > > What I'm taking away is that it may be possible to implement a purging > logic that does not rely on prefetching existing instances and marking > them as 'purging' (i.e. Type::Resources#generate), but work some agent > side magic instead. I hadn't been aware that you could resort to > scanning the catalog as in ProviderDemo#content. Very inspiring. > > Or am I missing a whole different point? I fear that the structure of > the demo provider can't solve the prefetching issue (i.e. the lack of > clean prefetching) by itself. > > Thanks and regards, > Felix > > -- > 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/52C99AE1.3090608%40Alumni.TU-Berlin.de > . > For more options, visit https://groups.google.com/groups/opt_out. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- 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%2BFoVE9JfAp-qpF8EniRo3rQaneVeVitj1%2B%3DcbcgRLZY-S%2Bg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
