Hi all, This just keeps coming up, again and again, so I decided to take a few hours and break everyone''s configuration. Oh, wait, just kidding. :) Really, I''ve completely rewritten external node support. Here''s the changelog entry: Only ONE node source can be used -- you can use LDAP, code, or an external node program, but not more than one. LDAP node support has two changes: First, the "ldapattrs" attribute is now used for setting the attributes to retrieve from the server (in addition to required attriutes), and second, all retrieved attributes are set as variables in the top scope. This means you can set attributes on your LDAP nodes and they will automatically appear as variables in your configurations. External node support has been completely rewritten. These programs must now generate a YAML dump of a hash, with "classes" and "parameters" keys. The classes should be an array, and the parameters should be a hash. The external node program has no support for parent nodes -- the script must handle that on its own. The biggest change is for those who are currently using an external_nodes tool -- I''ve broken compatibility with the old format. It should be easy to write a program to translate output from the old format into the new format, though, and someone could contract me to do this if they really wanted it. People who are using LDAP support have to deal with two changes: The attribute to specify the ldap class attribute has been renamed to ''ldapclassattr'', and now ''ldapattr'' is used to specify which attributes you want pulled from ldap and set as variables in your configuration. By default, this is set to ''all'' which means that all of the ldap attributes on a node will be set as variables in your manifest. Note that host facts override either of these node attribute sources. I could make this configurable if people want. Note that this is half-way to the functionality of kinial; in the end, kinial is really just a tool to be used as an external_nodes. Hopefully soon I''ll knock out the second piece. Of course, this isn''t released yet; it''ll be in the release I''m putting out ASAP (I just need to close the last 7 or so bugs in the fozzie milestone). I''d *really* appreciate it if people could test it, though, to make sure the behaviour I picked is reasonable. Not coincidentally, I''ve created a ''paypal@reductivelabs.com'' account. This feature seems *so* critical to everyone, I figure I deserve a tip. :) -- We''re not surrounded, we''re in a target-rich environment! --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Thu, 2007-06-14 at 21:57 -0500, Luke Kanies wrote:> The biggest change is for those who are currently using an > external_nodes tool -- I''ve broken compatibility with the old > format. It should be easy to write a program to translate output > from the old format into the new format, though, and someone could > contract me to do this if they really wanted it.How hard would it be to continue supporting the old format ? For simple things external tools (like shell scripts), generating YAML seems unnecessary .. or am I making more of this than it really is ? David
On Jun 15, 2007, at 11:54 AM, David Lutterkort wrote:> > How hard would it be to continue supporting the old format ? For > simple > things external tools (like shell scripts), generating YAML seems > unnecessary .. or am I making more of this than it really is ?Well, it wouldn''t be that hard, and I seriously considered it, but I don''t think it''s worth it. For one, the old external node support handled parent nodes, and the new one does not -- your external program is expected to know everything or nothing about a given node. This is the biggest reason why I decided to just break backward compatibility -- I want to push toward kinial instead of keeping the old model, and this is a good first step. For two, YAML is easy to generate in any language. Here''s the example output from one of my test scripts: --- parameters: l: fun ipHostNumber: | cool ness classes: - base - other A little indentation, some colons, and maybe a dash or two, and you''re fine. I really expected there to be a simple way to produce yaml output in the shell, but considering you need arrays and hashes for this information, it''s not exactly suitable for the shell, anyway. -- Really? He might do it just for fun. I know I would. If I were God, I''d get together with all my other God friends and have a big party. We''d all get drunk and create unliftable rocks, then try to lift them. It would be loads of fun! Then I''d probably just destroy the rocks with a lightning bolt. Then I''d probably pass out. :^) -- toMM, in rec.puzzles --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies wrote:> On Jun 15, 2007, at 11:54 AM, David Lutterkort wrote: > >> How hard would it be to continue supporting the old format ? For >> simple >> things external tools (like shell scripts), generating YAML seems >> unnecessary .. or am I making more of this than it really is ? >> > > Well, it wouldn''t be that hard, and I seriously considered it, but I > don''t think it''s worth it. > > For one, the old external node support handled parent nodes, and the > new one does not -- your external program is expected to know > everything or nothing about a given node. This is the biggest reason > why I decided to just break backward compatibility -- I want to push > toward kinial instead of keeping the old model, and this is a good > first step. > > For two, YAML is easy to generate in any language. Here''s the > example output from one of my test scripts: > > --- > parameters: > l: fun > ipHostNumber: | > cool > ness > > classes: > - base > - other > > A little indentation, some colons, and maybe a dash or two, and > you''re fine. > > I really expected there to be a simple way to produce yaml output in > the shell, but considering you need arrays and hashes for this > information, it''s not exactly suitable for the shell, anyway. > > -- > Really? He might do it just for fun. I know I would. If I were God, > I''d get together with all my other God friends and have a big party. > We''d all get drunk and create unliftable rocks, then try to lift them. > It would be loads of fun! Then I''d probably just destroy the rocks > with a lightning bolt. Then I''d probably pass out. :^) > -- toMM, in rec.puzzles > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >I''m thinking about trying to free various apps I work on from YAML dependencies, namely because of YAML 2.0 is getting a bit weird with flow-layout and the way YAML doesn''t like spaces at the ends of lines and has weird quoting rules -- it is also fairly easy to be making a innocuous hand edit and wreck a config file -- then the parsers aren''t very useful with explaining what''s wrong. As much as I don''t like XML, the syntax is actually easier to remember and type by hand (but not to read), which kind of defeats the purpose IMHO of using YAML. I know some folks are looking at JSON for this, which is why YAML 2.0 is working towards JSON compliance -- but it''s a loss on the human-readable/writable side -- since it''s not as skimmable as it used to be. --Michael
On Jun 15, 2007, at 5:21 PM, Michael DeHaan wrote:> > I''m thinking about trying to free various apps I work on from YAML > dependencies, namely because of YAML 2.0 is getting a bit weird with > flow-layout and the way YAML > doesn''t like spaces at the ends of lines and has weird quoting > rules -- > it is also fairly easy to be making a innocuous hand edit and wreck a > config file -- then the parsers aren''t very useful with explaining > what''s wrong. > > As much as I don''t like XML, the syntax is actually easier to remember > and type by hand (but not to read), which kind of defeats the purpose > IMHO of using YAML. > I know some folks are looking at JSON for this, which is why YAML > 2.0 is > working towards JSON compliance -- but it''s a loss on the > human-readable/writable side -- since > it''s not as skimmable as it used to be.I''d be fine supporting multiple input formats; it certainly shouldn''t be hard to do. We still wouldn''t have compatibility with the old format, since you can''t specify a parent node any more. -- Opportunity is missed by most people because it is dressed in overalls and looks like work. -- Thomas A. Edison --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On 6/14/07, Luke Kanies <luke@madstop.com> wrote:> Hi all, > > This just keeps coming up, again and again, so I decided to take a > few hours and break everyone''s configuration. > > Oh, wait, just kidding. :) > > Really, I''ve completely rewritten external node support. Here''s the > changelog entry: ><snip> . . . . . . .> > Of course, this isn''t released yet; it''ll be in the release I''m > putting out ASAP (I just need to close the last 7 or so bugs in the > fozzie milestone). I''d *really* appreciate it if people could test > it, though, to make sure the behaviour I picked is reasonable. > > Not coincidentally, I''ve created a ''paypal@reductivelabs.com'' > account. This feature seems *so* critical to everyone, I figure I > deserve a tip. :) > > --For us that are kinda slow . . . . Does this mean I can use $tool (perl, shell, python, etc) to update the LDAP directory with attributes such as those retrieved from facter? Can I simply pull facts from LDAP (ie $ipddress, $location, $memory, etc)?
On Jun 19, 2007, at 4:04 PM, Jeff Falgout wrote:> > For us that are kinda slow . . . . Does this mean I can use $tool > (perl, shell, python, etc) to update the LDAP directory with > attributes such as those retrieved from facter? Can I simply pull > facts from LDAP (ie $ipddress, $location, $memory, etc)?Essentially, yes -- Puppet will set any attribute in the LDAP object as a variable before compiling classes. Note the naming differences, though -- ldap calls them "iphostnumber", not "ipaddress". Note also that facts beat external node information -- if the external node tool provides an ipaddress value, and the client does, too (via Facter), the client wins. This is currently not tuneable, but it could be. Please, though -- give it a try. You should be able to stick data in ldap, create some sample classes that use that data, and then test it with puppet: puppet --use-nodes --ldapnodes --ldapbase="dc=domain,dc=com" mytest.pp Something like that, anyway. -- Everything that is really great and inspiring is created by the individual who can labor in freedom. -- Albert Einstein --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 19 June 2007, Jeff Falgout wrote:> On 6/14/07, Luke Kanies <luke@madstop.com> wrote: > > Hi all, > > > > This just keeps coming up, again and again, so I decided to take a > > few hours and break everyone''s configuration. > > > > Oh, wait, just kidding. :) > > > > Really, I''ve completely rewritten external node support. Here''s the > > changelog entry: > > <snip> > . . . . . . . > > > Of course, this isn''t released yet; it''ll be in the release I''m > > putting out ASAP (I just need to close the last 7 or so bugs in the > > fozzie milestone). I''d *really* appreciate it if people could test > > it, though, to make sure the behaviour I picked is reasonable. > > > > Not coincidentally, I''ve created a ''paypal@reductivelabs.com'' > > account. This feature seems *so* critical to everyone, I figure I > > deserve a tip. :) > > > > -- > > For us that are kinda slow . . . . Does this mean I can use $tool > (perl, shell, python, etc) to update the LDAP directory with > attributes such as those retrieved from facter? Can I simply pull > facts from LDAP (ie $ipddress, $location, $memory, etc)?As far as I have understood it, the external node script is a replacement for the LDAP stuff. It enables you to whip up any kind of script to create everything which is currently defined in nodes. My private use-case is creating/replacing site.pp with some database where all my servers are defined and configured: puppetmaster: +debian +etch +puppetmaster ip=192.168.0.1 munin_port=9999 vserver_host=vserver001 etc... Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGeFNO/Pp1N6Uzh0URAuH3AJoClJPXzHjmsGZvR8JY6qZimwhgEwCePia3 RlWcp8LU/xvAYqoHceGnGW4=fK+c -----END PGP SIGNATURE-----
On Jun 19, 2007, at 5:06 PM, David Schmitt wrote:> As far as I have understood it, the external node script is a > replacement for > the LDAP stuff. It enables you to whip up any kind of script to create > everything which is currently defined in nodes. My private use-case is > creating/replacing site.pp with some database where all my servers are > defined and configured: > > puppetmaster: > +debian > +etch > +puppetmaster > ip=192.168.0.1 > munin_port=9999 > vserver_host=vserver001David, You''re right, except that part of my announcement was that I''d updated LDAP support, also, to provide the behaviour he asked about. At some point, all of this will be moved into Kinial, though. -- The Washington Bullets are changing their name. The owners no longer want their team''s name to be associated with crime. So from now on the team will be known as The Bullets. -- Paul Harvey, quoting Argus Hamilton --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com