Hi, On Sun, Feb 14, 2010 at 3:31 PM, R.I.Pienaar <[email protected]> wrote:
> hello, > > ----- "Nat" <[email protected]> wrote: > > > 1. an external node classifier with variables passed in the > > parameters section of the YAML to nodes. > > 2. extlookup > > > My question is what is the conceptual difference between options > > 1 and 2? is there differences between scope of variables defined > > either way? > 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) 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. > with the node tool your essentially defining a whole long list of global > variables and they're available in all classes. You should know upfront all > the variables you need to define and (I think) you dont have a way to access > the facts of the nodes when you're doing the node tool output which makes it > hard to make decisions based on that. It also means your node tool need a > lot of knowledge/logic to set all these variables and defaults etc. I > recall something about facts being passed on STDIN but dont see it in the > docs so maybe i am wrong there and node tools do get access to fact. > 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:) > > with a node tool if you needed to set ntp servers based on country, or > facts or something you basically still need to write a lot of case > statements - the difference is you're just moving this logic driven decision > making from puppet manifests to the external node tool - adding a new site > generally either require code changes or a lot of work in modeling the data. > 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. ... Foreman does this nicely at the moment with its database structure but you > are restricted to the kinds of data it allows you to model, to model other > relationships would require code changes. (well, till extlookup supports > talking to it anyway then the two would make quite a good combination and > any effort you now put into using extlookup will pay off double then) > > > With extlookup you set the data requirements where used - in the class - > and where you are looking up the value you can also set a default, with > access to facts: > given the class: > > class ntp::config { > file{"/etc/ntp.conf": template("ntp.conf.erb")} > } > > looking at this you dont know what's going on, what does the ERB need, what > vars should your node tool pass? it takes a fair bit of digging to know > whats going on - say you're sharing your module with a mate who has his own > node tool. > > now consider: > > class ntp::config { > $ntpserver = extlookup("ntpserver", "${country}.pool.ntp.org") > > file{"/etc/ntp.conf": template("ntp.conf.erb")} > } > > you look at this and you know what data you can provide - and you already > know it degrades cleanly if you dont set anything sharing this kind of code > is much easier than the other one. > > Now your needs change and maybe today you need lookup ability for fqdn, > data center, country tomorrow you might also need one based on customer or > even something weird like time of day. With a node tool as i said you'd > need to go code this in, 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). > 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? The upcoming puppet feature where you have parameters per class can help > with the discovery phase of what data to pass but i am not sure how/if that > integrates with external nodes, didn't see that mentioned in the release > notes > > yes, there should be some way to tie with to the external classifier. Need more info... begin rant 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. 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) } end rant -- > 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]<puppet-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- 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.
