Thanks for the replies! While I don't like the idea of "reaching in" to a class to set its variables, given the design flaws in Puppet with parameterized classes, I agree that this is a strength of Heira (so far, the only one, IMHO). Maybe this irks me because I'm also a developer who started with C++.
I looked for docs and didn't find much beyond random blog posts, there are no "docs", really... I did read that article. I'm obviously a stalker. My (senior) co-worker that I'm training on Puppet is very much a pouncer. On Friday I had to say "no you actually need to read what it says" when trying to get him to use source instead of content (file type). He couldn't copy and paste, oh noes! I understand, though. I read a couple of the articles linked from that one, too, and there are lots of problems with them, and with the example Ashley gave (which the articles mention also). The NTP argument is pretty weak, IMHO. I don't think it's a great NTP module, I guess (I don't use it). =P No offense. =) I think the premise of supporting a new distro or OS (there is more than Linux out there, you know) with just variable flips almost silly. It practically requires modifying everything that will use that new OS. If all you do is flip a variable value, the module probably isn't very comprehensive. I almost always have functional differences for different OSes, like deploying an option file for a port, using .d files for some OSes and not for others, different templates, etc., not just a different package name. I completely agree with your finding #4. I keep reading about using Heira to include classes and it makes me cringe. That's such a terrible idea, and totally unnecessary, IMHO. It's trivial to include classes based on facts with Puppet itself, where all the rest of your structure is declared... Introducing a second area of declaring that stuff is just...ugh. I don't totally understand your variations...but I like the thought process and abstraction. It sounds like what I do all day long (on my "Puppet days"). I could see version numbers being useful in Heira: having a default and overriding it for dev or test. Instead of including instance::dev or instance::test classes, I guess, that do the same thing. We don't use version numbers at all in Puppet, though. =) This, however, is so far the only good use for Heira that I've found--overriding variables. I organize things into classes within a single module. I make high-level "functional" classes that group things together based on mostly non-technical stuff, like workflow or purpose, kind of like roles, and include those in nodes. These grouping are usually pretty well-defined, with limited scope. E.g. I have a few different support-group sub-classes (e.g.: support-group::research) that create different user accounts and set or override some parameters, or high level role classes like research-group sub-classes. I almost never include a class in a node manifest directly (usually just when testing). I have no node variables or top scope variables. We have lots of HPC clusters, from 1 or 2 to entire racks of machines, so putting everything into classes as a policy and habit really helps us. This eliminates almost all problems with overriding variables so far. I guess if we need to split something up (like different "types" of NTP server), I would create classes for them and include those where necessary. I'm not sure if/how Heira can help with this yet. The only real "problem" I have is user accounts integrating with various other things (like NFS/no NFS/root squash/pam_mount *and* AutoFS on the same box). We have a very big, very flexible user define with a layer on top of it for some corner cases. It's a lot of functional differences. I'm not yet sure if Heira could help with this, either, but it's something I'll be looking into... I might try to track my journey and make blog posts to help codify what I learn. Maybe someone will find it interesting or useful if they get into the same situation... GOodnight, Josh On Sun, May 5, 2013 at 2:04 PM, Larry Fast <[email protected]> wrote: > Hi Josh, > Here's what we found. I would love to hear about other approaches because > we're still debating and building out our service. > > 1. Yes it's a great way to escape from parameterized classes. If you ever > needed to 'include' a class in two places, parameterized classes makes this > difficult or impossible. > 2. I don't recommend using automatic hiera lookup. There are some subtle > gotchas in it especially when using hashes in hiera. In my office our > recommended practice is as almost as you wrote it, class bar ($foo = > hiera('bar::foo')) { ... }. Hiera automatic lookup is a good way to allow > an easier transition from parameterized classes so it may still be a good > choice for you. As Ashley points out, read the latest docs! > 3. If you explicitly use the hiera() call, you'll get nice "variable not > found" messages when you make a mistake. Clear error messages are rare in > puppet so don't underestimate their value. > 4. Don't over complicate your hiera tree. It's not the place for > everything. Pick your largest collection of system-to-system variation and > put that in hiera. > > In our office we identified three variations that we *wanted* to put in > hiera: > 1. Variation between servers *within* an instance of our service > 2. Variation between similar servers across different instances of our > service (eg. Identity of the zookeeper in production, staging & QA) > 3. Version differences between instances of our service. IE. use hiera to > manage the pipeline of releases. > > What we *actually* put into hiera was only #2. When #1 started creeping > into hiera things got very messy. #1 is better handled by managing server > Roles. #3 should never go into Hiera - but I'm still arguing this point > with my co-workers. > > Caveate Emptor: We're still hemming and hawwing about all this. > Cheers, Larry Fast > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Puppet Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-users/Z7GTiygw294/unsubscribe?hl=en > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
