On Dec 17, 2009, at 11:19 AM, Al @ Lab42 wrote: > On 17 Dic, 17:28, David Schmitt <da...@dasz.at> wrote: >> Hi Al, >> >> Welcome back, great post! >> >> +1, except for (as predicted) #8, where I think that the rationale >> doesn't make sense, especially if one wants to start configuring >> modules >> via facter and/or external nodes. prefixing with the module name >> would >> make more sense for me. >> >> Regards, DavidS > > Hi David, > thanks for the reply. > You and Michael have definitively convinced me about variable name > namings (modulename_ is surely a better prefix). > > I take the occasion of your reply to discuss deeper a topic that I've > always found somehow controversial. > Many use to say, if I've understood well, that in a puppet > infrastructure there should only be variables generated by facts, that > it's not a good idea to define custom variables at node's level (or > using different ways to group/classify them). > I can understand this if we talk about external nodes, when you can > have powerful and easy ways to aggregate/define variables for nodes > (and still they are not fact variables), but I still have to > understand why and how it should be better to define variables > necessary for your classes (for example an external server where to > send syslog messages, which changed according to different servers' > locations or test/prod status or whatever logic) in a fact. > > I find more difficult to write and control this logic in custom facts > splattered in different modules, rather that in a single > "infrastructural" class where all variables are defined according to > custom logic and groupings, or, as I generally do, in a nodes' > inheritance structure, where there are intermediate node that can > define networks or geographical locations or whatever groups that are > inherited by host nodes. > > Excuse my ignorance, if someone can enlighten and convince me on the > advantages of placing the logic of a puppet infrastructure in facts, > please do it. > I like to redefine my beliefs :-D
I'm playing a bit of catch-up on this thread, so bear with me as I work through it. First, to address using variables for logic: I would never recommend anyone rely entirely on facts for configuration - quite the opposite, I would recommend people *only* use facts for cases where the client is the only host capable of generating or discovering a given piece of data. For instance, I think it's bad form to send a fact to the client whose value is static or relies on a database (or data file) also distributed with the fact. I think server-side functions (usually doing a DB call) is a much better choice. I see, at the least, these sources of data: 1) Client facts -- discoverable and/or calculable only on the client 2) Declared client data -- declared in external node tools by a human, per-node or per-server class etc. 3) Dynamic data -- retrieved with an extlookup-style function or equivalent which essentially uses a db backend for all of its data but has some understanding of class logic that can selectively load data Then, of course, you have essentially internal temporary variables whose value entirely derives from one of these three sources. Any attempt to push any of these behaviours into a different data type will hurt. Obviously we have to answer this question in terms of standards, but for me the more interesting question is how we should develop Puppet going forward. It's obvious to all of us that Puppet doesn't perfectly solve all of these problems, and I'd much rather fix those issues than calcify standards that work around fixable problems. Here are some steps I think we need to take that will help this considerably: 1) Consider any system running without an external node tool to be in a degraded mode. That is, you've chosen to forego an entire data type in your system, so you've got less functionality. There are now multiple functional external node tools, one of them supported by Reductive Labs, so there's no good reason not to at least plan on using one in the near future. 2) Integrate an extlookup-like functionality directly into Puppet classes. This has been discussed a bit, but no real design has been proposed, much less decided upon. I'd like some kind of data interface that can support multiple backends and then have classes automatically look their data up, rather than having to trigger the lookup as functions currently require. There are some other features I think we need, but I'll add them to my response to the opening email because they're less data-focused. -- There is nothing so useless as doing efficiently that which should not be done at all. -- Peter Drucker --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
