Why External Node Classification is my future (was: Re: 'Considered Harmful' Considered Harmful)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 26 October 2007, Luke Kanies wrote:
> I actually think I've found a way to fix the majority of the
> confusion around using node inheritance, but I want to see how hard
> it's actually going to be before I go sending a complicated email
> about it.  The summary is that it would make all class scopes have
> the node scope as their parent scope, so that classes could look up
> variables defined in node scopes.

I don't think that adding a exception to the way scopes work would make the 
situation better in the long run. For me, the really simplest workable model 
when thinking about nodes is the seperate external node classifier (ENC). The 
ENC defines a node as a set of top level variables and classes. Making that 
distinction really lets me see the information coming from the ENC as "the 
configuration", while modules and other included classes are "just" libraries 
to be used. Using a bit constraint on what is written in the site.pp (e.g. by 
using "template classes") this functionality can be emulated today.

Of course this still leaves open the problem with site- and node-specific 
resources which do not lend themselves to be put into a class like the 
recently mentioned network interfaces or my own hosting_vserver definitions.

In my ideal world though the latter problem would rather be fixed by extending 
the ENC to handle resources too, instead of hacking into an already complex 
area, namely scoping. Also, creating resource in the ENC would have the 
additional benefit of enabling resource creation e.g. from a third party 
database. Like hooking up puppet into your webshop or user management 
interface. 

More pragmatically, the ENC could include $hostname and $fqdn, which could 
then hold additional per-node resources, already inheriting all the 
configuration settings from the ENC.


Regards, David

- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHIkiP/Pp1N6Uzh0URAqEDAJ0eGirA8c7macB9n6rz2ZpmHgOeqACdHLAV
XpPZmTNwbxJ0gwTlPF50KqI=
=EOVo
-----END PGP SIGNATURE-----