Hi, necro-bumping yet another thread, I took another stab at that old problem.
I molded Jeff's approach into a form that I hope to be more palatable. It does not break any tests that I have tried (which is not saying it won't break any whatsoever). https://github.com/ffrank/puppet/tree/dont-always-retrieve-service-ensure So, if you guys could give it a spin, that would be awesome. Also, a ticket would be helpful, but if you can confirm that this works and helps, I can open one on your behalf so we can make a PR for this. Cheers, Felix On 12/19/2013 11:39 PM, Jeff Bachtel wrote: >>> >>> In the end, even just the behavior change to "puppet resource" makes >>> the patch a non-starter because it is a widely used feature. >> >> I understand this feature should be kept, but that a pity this should >> impact other even more useful feature like "apply" or "agent". >> >> Could it be possible that "puppet resource" and other like "apply" or >> "agent" retrieves only what they need? In apply/agent case, this come >> from a transaction being applied. For "puppet resource" I assume this >> is not the case. Could method parameter solve this case? And this >> could even keep the compat if this param is not specified >> > > I spent all day (because my Ruby is bad) doing a proof of concept with > this. It touches type.rb and indirector/resource/ral.rb to add a > seemingly transparent method variable flagging whether ensure should > be ignored for the purpose of retrieving resources. It defaults to > false (don't ignore ensure), which should cause the speedup Aurelien > is needing. The resource RAL indirector is aware of the method > parameter and sets it to true (ignoreensure), thereby exhibiting the > old behavior when puppet resource is called from the command line. > > There is a nasty bit that I'm unsure of in the retrieve_resource > method. I discovered that when running puppet agent -t --noop, if I > tried to use my newly defined method parameter that parsing would > choke - apparently in that state the retrieve method is targeting > another method. I worked around it by putting in a rescue statement > and falling back to the old way of calling retrieve which should, > eventually, still hit the retrieve with Aurelien's improved > conditional logic. > > Anyway, please find attached a diff containing the changes in > question. Feel free to refine and submit it as a PR, my Ruby really > isn't up for my doing so myself. > > Jeff > > -- 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/5366D861.1040304%40Alumni.TU-Berlin.de. For more options, visit https://groups.google.com/d/optout.
