Issue #2157 has been updated by Ken Barber.
Updates to my branch since last comment: * Changed logic so a TTL of zero means never cache, and -1 means cache forever. This got rid of a couple of oddities in how we were treating absent TTL with a zero. This is less surprisingly as well IMHO. * Ignore mixed case for extension handling. This is mainly so windows users can mix case and the external scripts will still work as expected. * I've re-factored the cache class so now its a static class. This is so I can tap the cache from different places instead of handing a cache object around. This paves the way for Ruby based caching. * I now cache data even if the results were nil. A nil result is not considered a failure necessarily and better to cache these operations as valid returned data. * Changes cache serialization to use Marshal not YAML. This file is internal anyway and under heavy writes I saw much better performance. I tried just 'writing at the end' but Facter has multiple entry/exit points its hard to do a final 'write' of a cache at the correct place and be assured this would work each time. Increasing the performance of the cache writes by using Marshal was a simpler solution - at least for now. * Added cache support for ruby facts. You can now pass an option of 'ttl' to a Ruby fact upon creation and it will be cached much like we have been doing for external facts. Using this mechanism and turning on cache for most of the facts I was seeing performance improvements from 2100ms (unprimed cache) to 230 ms when cached which is awesome. However a point of note is that the ec2 gem does most of its work out of setcode, whereas I pretty much only cache the setcode part. This could potentially be fixed with hierarchal data support (which would move all the logic inside the setcode). Just need to make this point now to be clear. * I have _not_ committed any change of TTL in the existing facts (although I have obviously tested working with TTL on our existing facts). I would imagine this to occur later when people are ready and all the desired feature sets are shaken up. I now will return to the path issues for windows (and for Linux) as I see this as the last major roadblock to this work. Also - we will need to handle path creation in install.rb most probably. I need to handle failure when paths don't exist/aren't writeable etc. There has already been a discussion about these path issues which is covered here: https://groups.google.com/group/puppet-dev/browse_frm/thread/74682b39a943b809# ---------------------------------------- Feature #2157: External fact support in /etc/facter.d https://projects.puppetlabs.com/issues/2157 Author: Paul Nasrat Status: In Topic Branch Pending Merge Priority: Normal Assignee: Ken Barber Category: Target version: 2.0.0 Keywords: Branch: kbarber/tickets/master/2157-external_fact_support Affected Facter version: Facter should support non-ruby facts, preferably in /etc/facter.d. It should support these facts being either executable, in which case the result is the value of the named fact, or in a data format such as yaml, in which case the data file is read in and interpreted as the fact value. It probably makes sense to initially stick to yaml for data formats, since json doesn't ship with ruby, and to also allow executable facts to return either a plain string or yaml. Note that we can do this without supporting any kind of overriding, but it'd be much better if we supported multiple (configurable?) fact directories, with a search path. Thus, if Facter shipped with /etc/facter.d/myfactname and you wanted to override it, you could do so by creating a new file and putting it in a higher-priority location rather than editing a file distributed with the core. Given we're adding structured data support, namespaced facts would be supported with directory structures; e.g., /etc/facter.d/my/fact/name would resolve to my::fact::name. Ideally, the long-term direction here would be not to require any pure-ruby facts, such that the Facter library could be rewritten in any other language and it would function the same, because all of its actual data is outside of ruby. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
