> Hey y'all:
>
> To go along with Jesse's announcement on ShadowPuppet [1], I'd like
> announce ShadowFacter, a wrapper around Facter that supports
> namespace and easy integration into Ruby code like Rails
> applications, Capistrano, RSpec, or Rake. This project is part of
> our work on our Moonshine [2] deployment system which is built on
> top of Git, Puppet and Facter.
>
> ShadowFacter supports constraints, reloading facts by namespace, and
> dumping facts to YAML and JSON. ShadowFacter facts are backwards
> compatible with the existing Facter environment and can be added to
> FACTERLIB for display using 'facter'. Also, check out 'lens' in the
> examples directory, a simple Sinatra-based web server that serves
> facts as JSON.
>
> Source: http://github.com/railsmachine/shadow_facter/
> Rdoc: http://railsmachine.github.com/shadow_facter/
> Sample Manifest: http://github.com/railsmachine/shadow_facter/blob/master/examples/lib/facts/kernel.rb
> Lens - a simple server: http://github.com/railsmachine/shadow_facter/blob/406d5354f6c9b085cf87b24a976e10efca6f0069/examples/bin/lens
>
> We released these two projects to get feedback and are open to
> merging in Puppet and Facter core. Please let me know what y'all
> think or have any questions.
I really like this idea of a new skin on the existing API - it allows
us to define a new, improved interface while retaining backward
compatibility.
I definitely want to get this integrated for Facter 2.0 (1.5.3 should
drop tomorrow -- if anyone wants to test...). I expect a few bits
will come out here and there as we attempt to integrate and test it,
and I know there are some features in ShadowFacter (e.g., the ability
to run facts from the command line) that don't fit Facter's current
architecture, so we'll have to figure that one out.
Overall, though, this is great, and I'd love to see it integrated as
quickly as possible.
--
God loved the birds and invented trees. Man loved the birds and
invented cages. -- Jacques Deval
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
"Here are the issues that jump out at me. I think you could integrate
any of these independently.
1. Fact definition syntax including namespaces
2. Fact parsing/storage/access
3. System-wide fact aggregation
4. Output/presentation (cmd line tools, server, api)
5. Backward compatibility"
Thoughts and discussion on these concepts and ideas welcome.
Cheers
James
- --
Author of:
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkl/6agACgkQ9hTGvAxC30CvXQCfewRSyp33Fqr+g55vCEqYinwM
3msAniz8S1nEV8dcl5WFkBtqDfrgmY3K
=T+QA
-----END PGP SIGNATURE-----
To me, #1 and #5 are the most important to start with. Providing a
simpler, cleaner, more functional interface with backward
compatibility is a significant win.
I think the main thing is to start small and integrate things a piece
at a time, so that it's always approachable and tactical, rather than
a huge chunk of work that will take forever and not be usable until
it's entirely finished.
--
We cannot really love anybody with whom we never laugh.
--Agnes Repplier