Issue #2157 has been updated by Ken Barber.
Nigel Kersten wrote: > Ken Barber wrote: > > * 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. > > Isn't there a problem with different versions of Marshal support being > incompatible with one another? Interesting point. It is a concern, although I'm more worried about errors, then trying to preserve data across Ruby upgrades. So let me drill down into more detail ... if I use YAML using the current Cache mechanism, the cache will get written each time there is a cache change. When you get up near the ~100 fact mark something that took 2 seconds will now take 3 seconds for that first run. Obviously subsequent cached runs are much much faster, but the last thing I need is a big delay for that first run. Now I could find a way of writing once, which does work when I say put this write in facter/application.rb or in load_facts or some other catch-all place - but this will _not_ work if someone just uses Facter.value in their application. If I put it somewhere in Facter.value ... well ... I have limited means of telling if this is a once off call or a full fact run thus leaving us with a write per cache change again. So either I find a place to limit the amount of writes ... or I use something faster like Marshal to get around the perf hit. I still want to keep the cache mechanism very simple ... so whatever mechanism we use should be fast and available with standard Ruby. I could just look for Marshal version exceptions (TypeError) and alert on them or perhaps overwrite the file using the new format. I don't see this is as a massively complex work-around, although I would need a clean way of picking up false positives (since even just junk data throws a TypeError it would seem). Interesting: switching between 1.8.7-p334 and 1.9.2-p290 doesn't throw this exception. ---------------------------------------- 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.
