hello, > with regards to scope, its possible that extlookup is more reliable > since it determines the value for the config inline, thus removing any > chance that a global variable assiged from the classifier would be > overridden from an enclosing scope. This scoping issue for the > external node classifier can be solved by namespacing the params, I > used my_ for this (although this wouldnt work well when classes will > have constructors in Rwolf)
sure, but it just shows why global variables have been abandoned by all but the most sucky devs and languages, puppet has some way to go to make this easy for us to do the right thing :) > In my view, they are functionally equivalent an even similar. They > both rely on code that looks up params from an external source. The > external node classifier does it before the puppet run then applies > the params at top scope, where extlookup determines the information in > your puppet code. for me the simplicity of how extlookup does it appeals, 100 lines to have something that achieves this compared to super complex node classifiers. > There are ways to access facts from an external node classifier. > Namely, by parsing the $varlib/nodes/facts/HOSTNAME.yaml file (which > is guarenteed to be created before your external node classifier is > run) I agree this is not the cleanest way to do this, and have even > opened a ticket several months ago > http://projects.reductivelabs.com/issues/2356 (before I worked at RL:) yeah, hacky though, I wouldnt suggest that a node classifier being on the same box as the master is a good idea. > I see this a little differently: the node tool needs a way to assign > which groups of params should be assigned to which nodes. The groups > of params should support inheritence. > > default > / \ > site 1 site 2 > / > subnet 1 > / > application > > all of the conditional logic for assigning groups of params to nodes > should only be written once. After that, changes should just involve > configuration. I agree, however, 100 lines of code to achieve this the way extlookup does, I'd very much love a node tool like this, but it would be a long painful process of coding, bug fixing etc. > I disagree with this assumption. I think that with a node tool (ifs > its written correctly), you would just have to choose the groups of > params that you want to use. If your requirements change, then just > reassign a different group of parameters (or change 1 of the param > values for a group). there's no such tool - at least not in public domain, again I agree with you but it would take ages to write a fully flexible node tool, foreman and dashboard both suffer from a lot of assumption about how the authors/designers thinks architectures should work that doesn't translate well to all cases. > with extlookup you just configure it in one line of config. > > > Wouldnt there be cases where you have to change every line of puppet > code that uses the extlookup tool if the properties that determine the > lookup change? not that I can think of. > I have this idea that the ideal solution is a combination of using > both an external node classifier as well as an extlookup tool. > > The classifier handles the assignment of gorups of params based on > inheritance. > > Most param information is determined by some external feature of a > node. What site am I at? What DC? What subnet? What is my role? These > params should be assigned by an external node classifier. This allows > us to control how these values are assigned outside of the scope of > our puppet code. These are facts about a node, it should be on the node and it has a lot of use being on the node (see how mcollective does discovery for example). though that said, nothing prevents you from just writing a list of classifier provided facts onto the node to achieve the same. > Some param information is always determined by some fact about our > node (think platform). These types of params should be set with an > extlookup tool (or something similar). This extlookup tool should just > be accessing config from some kind of per module config fille. Think > about how strings vary between platform, arch, fact an an > internationalization problem. > file{'ssh': > name => extlookup(ssh-name, $operatingsystem) > } there's stuff that extlookup can do that no node classifer can do in the current model, extlookup has access to the existing scope, you could lookup $ntpserver from extlookup in one class and get one answer while in another class you'd get another based on variables and values in scope at the specific time. a bit contrived in this example but it has uses. something where i find extlookup invaluable is with package management: define mypkg() { $ver = extlookup("package_${name}", "present") package{$name: ensure => $ver} } mypkg{"puppet": } I can now like I often do when new puppets come out just configure my development environment to go to the next version, then I'd do machines in the states, then uk and za and finally germany all by just adjusting the data. Or one specific client insist on having screen on his machines, no problem extlookup search for my $client fact and i can enable screen just for him by manipulating the data only - this kind of flexibility is invaluable in sites like mine where I host 10s of customers worth of kit on the same master. -- R.I.Pienaar -- You received this message because you are subscribed to the Google Groups "Puppet Users" 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-users?hl=en.
