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.
