(CC'ing the dev list, because this ended up being a very informative
email.)
On Oct 28, 2008, at 3:26 AM, Brice Figureau wrote:
> I'll read the code to see how it works. Until now I only surfaced this
> part. I understand the concept, but I'm not yet familiar with the
> internals.
> Something for instance I don't know is how the back-ends are
> registered
> to the Indirector. And how a client of the indirector can choose a
> specific back-end (does it have the choice, anyway?).
The back-ends (currently called terminuses, or terminii in the pseudo-
latin form) are registered using an autoloader similar to the rest of
Puppet: You store the code for the backend at indirector/$indirection/
$terminus.rb.
So, Nodes (that is, Puppet::Node) have an 'ldap' terminus type, stored
at indirector/node/ldap.rb.
Similar to providers, you'll see base classes for those terminus types
at (in this case) indirector/ldap.rb.
The autoloader knows how to find and load the files, but the
registration process is actually kinda messy (although you can largely
ignore it, with a couple of caveats). I'd like to replace it at some
point, but it's not a high enough priority.
All of the terminus types are subclasses of the
Puppet::Indirector::Terminus class, but they *require* an in-between
base class -- this is the messy part. And it has to be exactly one
base class; you can't, say, create a subclass of a subclass of a
subclass of Terminus.
The registration is also automatic based on constant name -- the class
Puppet::Indirector::Node::Ldap always means a terminus named 'ldap'
for the indirection named 'node'. You'll notice that the Node class
specifices 'indirects :node' -- this is it declaring the name it wants
to be known by, and this name is used to register terminus types.
There are cases where we don't use the class name (e.g.,
FileServing::Metadata becomes :file_metadata).
90% of the code is in indirector/indirection.rb -- the connection
between the Indirector, an indirected class, and all of the terminus
types is called an Indirection, and nearly all of the functionality is
in there.
Really, though, you can just about ignore all of that, as long as your
terminus types are subclasses of a subclass of Terminus, and you get
your constant names/indirection names correct.
Once you have all of the code -- the indirected class and all of the
terminus types -- it's just a configuration problem. The majority of
the time, configuration is static and is done at startup. For
instance, puppetmasterd declares 'Puppet::Node::Facts.terminus_class
= :yaml', which says that facts will always be stored in and retrieved
from yaml (this works because the client uploads facts to the server,
which the server then sticks on the filesystem).
There are a couple of cases where things work differently: The node
terminus is configured with the 'node_terminus' setting, and
file_serving terminus types are dynamically determined based on the
URL; e.g., puppet:/// file sources go to the REST terminus but
file:/// sources go to the local file terminus.
For most cases, it will suffice to have per-executable static
configurations (puppetd will always use REST for most of its
connections, and yaml or something similar for caching), but as we
integrate Puppet with more applications, we're going to want the
ability to configure executables to use different stores. E.g., I
want to move storeconfigs to a Resource indirection, and then support
more than just ActiveRecord on the backend, and really, I'd like the
client-side catalog cache to support more than just yaml (so we could
do things like track changes).
Feel free to ask for more detail.
--
Susskind's Rule of Thumb:
Don't ask what they think. Ask what they do.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" 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-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
