Hi,
I''d like to use ENC::
http://docs.puppetlabs.com/guides/external_nodes.html
to keep hardwired customizations away from our classes and other files as
much as possible
particularly for the node name, but potentially as esoteric as a machine
configuration, file
permission, service name, etc - to keep the classes as flexible and general
as possible.
My questions:
+ have you done the above?
+ what were your learnings
+ do you have sample puppet_node_classifier''s you can share?
+ how to use the definitions from ENC via the pm''s
puppet.conf''s linkage
to the ENC
[main]
:
node_terminus = exec
external_nodes = /usr/local/bin/puppet_node_classifier
:
My current question is how do you use the ENC definitions within the
classes?
Is this adequately described in-depth in the yet-to-be-published Puppet
book?
Stuart
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/7b5670b1-8ca6-4d63-bb38-3d0e5f5bfae6%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Stuart, Yes, many of us use ENCs, though it seems to be mostly limited to larger shops; these days many people are moving in the direction of hiera instead. I''ve been using various ENCs for the past ~4 years. There are relatively few good choices for already-written ENCs. (well, if you just want a simple script, you can write it yourself; most of the "ENCs" that are available provide a web interface for configuring everything). The most popular options that I know of are Puppet Dashboard (aka Console in Puppet Enterprise) and Foreman. The current version of Dashboard (IMHO) has some serious issues, though PL is actively working on them and I''m told that big improvements can be expected. Foreman is good, solid software but does a LOT in terms of provisioning, DNS and DHCP control, etc. as well as a lot of internal logic about setting variables and classes, etc. so I feel that it''s a bit much if all you want is a plain-and-simple ENC. I''m in the process of polishing up my company''s internal ENC, and plan on releasing it on github. It''s a python/Django app that supports multiple inheritance and overrides, class and parameter exclusions, and has full support for parameterized classes and deep data structures. That being said, I''ve also written ENCs in the past that were quite simple - type in a hostname, check off some boxes for classes and groups, and you''re done. As to samples - unfortunately, no, I don''t... but you just need some script that prints valid YAML according to the spec. Without knowing more about how you want it to work, I can''t provide much of an example. "My current question is how do you use the ENC definitions within the classes?" Well, most of the ENCs I''ve used in the past (Puppet Dashboard included) just return a list of classes to apply to the node, and a list of parameters. The parameters are passed to puppet as top-scope variables. So your ENC defines a parameter called, say, httpd_version, and somewhere in your httpd class, you use $::httpd_version. Of course then you really need to follow the params.pp pattern to declare a default value, and validate what the ENC passes in. This pattern really sucks. Lately, especially since puppet3 came out, I''ve been using an ENC that supports parameterized classes. So I don''t do anything special in my classes (in fact much of what I use are modules from the Forge), and I just tell the enc what classes I want, and the parameters that I want passed in to them. This allows me to use many of the forge modules (especially the puppetlabs ones) straight from my ENC. I''d be happy to provide a bit more advice if you have more specific questions. -Jason On 12/03/2013 06:50 PM, Stuart Cracraft wrote:> Hi, > > I''d like to use ENC:: > > http://docs.puppetlabs.com/guides/external_nodes.html > > to keep hardwired customizations away from our classes and other files > as much as possible > particularly for the node name, but potentially as esoteric as a > machine configuration, file > permission, service name, etc - to keep the classes as flexible and > general as possible. > > My questions: > > + have you done the above? > + what were your learnings > + do you have sample puppet_node_classifier''s you can share? > + how to use the definitions from ENC via the pm''s puppet.conf''s > linkage to the ENC > > [main] > : > node_terminus = exec > external_nodes = /usr/local/bin/puppet_node_classifier > : > > My current question is how do you use the ENC definitions within the > classes? > > Is this adequately described in-depth in the yet-to-be-published > Puppet book? > > Stuart > > -- > You received this message because you are subscribed to the Google > Groups "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to puppet-users+unsubscribe@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/7b5670b1-8ca6-4d63-bb38-3d0e5f5bfae6%40googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out.-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/529F2359.4060801%40jasonantman.com. For more options, visit https://groups.google.com/groups/opt_out.
On Tuesday, December 3, 2013 5:50:47 PM UTC-6, Stuart Cracraft wrote:> > Hi, > > I''d like to use ENC:: > > http://docs.puppetlabs.com/guides/external_nodes.html > > to keep hardwired customizations away from our classes and other files as > much as possible > particularly for the node name, but potentially as esoteric as a machine > configuration, file > permission, service name, etc - to keep the classes as flexible and > general as possible. > > My questions: > > + have you done the above? >I''d like to think that I write flexible, general classes. That''s pretty much orthogonal to use of an ENC, however, and in fact I do not use an ENC. You are quite right, however, that a big part of making your classes flexible and general is to keep data out of classes -- that is, to externalize your data.> + what were your learnings > + do you have sample puppet_node_classifier''s you can share? > + how to use the definitions from ENC via the pm''s puppet.conf''s linkage > to the ENC >I don''t think I understand the question. Your puppet.conf specifies the ENC to use. Each time a node requests a catalog from the master, it runs the specified ENC program, passing the node''s identifier as an argument. The master parses the ENC''s YAML output to obtain global variable settings and the names of classes that should be declared for the given node, optionally with associated maps of class parameter values. These may be supplemented by node declarations appearing in your manifests. You don''t actively "use" definitions from an ENC; rather, the master automatically incorporates the ENC output as a source of declarations about the target node. ENCs are a non-exclusive alternative to node declarations. If what you are looking for is simply a way to externalize data used by your classes, then hiera is Puppet''s built-in facility supporting that. Open-source Puppet does not provide a GUI for hiera configuration or hiera data manipulation (I don''t know about PE), but the general thrust of your questions leads me to suspect that that may not be important to you. Hiera supports automatic binding of data to class parameters, but its classic usage mode is via a lookup function in your manifest code: $my_special_datum = hiera(''special'') . Thus, you can draw data from hiera without using parameterized classes or in addition to via automated class parameter binding, if you should wish to do so.> > [main] > : > node_terminus = exec > external_nodes = /usr/local/bin/puppet_node_classifier > : > > My current question is how do you use the ENC definitions within the > classes? > > Is this adequately described in-depth in the yet-to-be-published Puppet > book? > >I can''t speak to the content of any unpublished book, but I think the PL docs cover the matter pretty well already: http://docs.puppetlabs.com/guides/external_nodes.html. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0a909355-1436-4a66-91ae-5c0f755268ad%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Chapter 5 at page 119 in the Pro Puppet book of 2011 by Turnbull/McCune has good explanation and scripts, in Shell, Perl, Ruby. On Tuesday, December 3, 2013 3:50:47 PM UTC-8, Stuart Cracraft wrote:> Hi, > > I''d like to use ENC:: > > http://docs.puppetlabs.com/guides/external_nodes.html > > to keep hardwired customizations away from our classes and other files as > much as possible > particularly for the node name, but potentially as esoteric as a machine > configuration, file > permission, service name, etc - to keep the classes as flexible and > general as possible. > > My questions: > > + have you done the above? > + what were your learnings > + do you have sample puppet_node_classifier''s you can share? > + how to use the definitions from ENC via the pm''s puppet.conf''s linkage > to the ENC > > [main] > : > node_terminus = exec > external_nodes = /usr/local/bin/puppet_node_classifier > : > > My current question is how do you use the ENC definitions within the > classes? > > Is this adequately described in-depth in the yet-to-be-published Puppet > book? > > Stuart > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/30c4f26c-9fec-4419-a9ab-674c0cefc7aa%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.