| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, for example, the configuration terminus that was a
subclass of 'code' would have been stored at
lib/puppet/indirector/code/configuration and would have had
to have been named 'configuration'. Now, the subclass
can be named however the author prefers, and it must be stored
at lib/puppet/indirector/configuration/<name>.rb, where <name>
is the name you've chosen for the terminus type. The name only
matters insomuch as it is used to load the file from disk and
find the appropriate class when asked.
The additional restriction is that the class constant for the terminus
type must have its name as the last word, and the indirection must
be the second to last word. Thus, in our example, we can choose
any class constant that ends with Configuration::Code; given that
there's only one Configuration class at this point, it makes the
most sense to define the class as Puppet::Node::Configuration::Code.
This is somewhat awkward, because of the class's location on disk,
but the only other real option is to autogenerate a
Puppet::Indirector::Configuration class constant, which is, I think,
uglier.
|
|
|
been migrated over to the new organization. Where we
would have previously had an 'ldap' node terminus at
puppet/indirector/node/ldap.rb, we would not have it at
puppet/indirector/ldap/node.rb, and it would be a subclass
of puppet/indirector/ldap.rb.
These are called terminus classes, and there are now three
categories of them: The base class itself, abstract classes
that provide most of the functionality (e.g., the ldap and
yaml classes), and the classes themselves that implement
the functionality for a given model like Node or Facts.
The base terminus class handles auto-loading any of these
classes from disk.
|
