There is a module on the forge that implements what Jeff suggested. http://forge.puppetlabs.com/nightfly/ssh_keys
Cheers, William On Sun, Jan 5, 2014 at 1:42 PM, Trevor Vaughan <[email protected]>wrote: > 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. > -- 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/CAEXKxLw3vbe%3DmK%2Boa1Nfhi%2BgcPU6-Y9zL2D2YayXE8qOEycaDA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
