On Tue, Aug 31, 2010 at 2:26 PM, Luke Kanies <[email protected]> wrote: [snip] >> That same hierarchy lends itself, SNMP-like, to grouping facts as leaf nodes >> in a tree of naming. >> >> com.puppetlabs.ipaddress.eth0 => 192.168.1.1 >> com.puppetlabs.ipaddress.eth2 => [172.16.23.1, 172.16.24.1] > > Hmm. I've never thought of this. I've always kind of hated the > reverse-domain style naming, but it's certainly common, and my opinions have > often been wrong on this. Anyone else desirous of this?
I'm impartial to reverse-domain style naming, but I've always loathed my inability to quickly determine if a variable is a fact, a parameter from the ENC, or was defined elsewhere in a manifest. When I write my own facts, I prefix them with "fact_" and then prefix again with "org_" so my facts look like "$fact_acme_datacenter" which helps me read my code quickly. "Ah, this is a fact I wrote while at acme" This sort of looks like a reverse domain style, so I guess I'm not as impartial as I originally thought. I'm totally on board if the scheme helps me quickly identify where a variable originated from while scanning through code. It's not a show-stopper for me, but it'd be nice. > It wouldn't translate all that well to Puppet variables - > $com::puppetlabs::ipaddress::eth0? I actually don't have a huge issue with this. $fact::acme::datacenter $parameter::acme::globalstop That's not so bad to my eyes. For better or worse my variable names are often longer and more verbose than the norm, so that might explain why this looks OK to me. > I think it would also make overrides and things a bit complicated - is a fact > in com.puppetlabs a fact that we shipped the code for, or a fact about a > Puppet Labs project? Both? I don't really see the difference, but maybe it's lack of sleep. If it's a specific project, I'm fine with being more verbose, $fact::puppetlabs::dashboard::version which follows the convention, e.g. com.sun.java It's long, but helps me understand the code and context quickly. > Should a Solaris IP address have a different path than a Red Hat IP? Nope. I think it should be $fact::puppetlabs::ipaddress if we adopt this model. > What if you override the default IP fact with a custom one? If Acme wanted their own ipaddress fact, they could implement $fact::acme::ipaddress Scanning Acme's code quickly, I would quickly understand they implemented their own fact for ipaddress. > However, I can totally see naming the resolution mechanisms that way - we > need a unique way of naming and finding resolutions, both for logging and > testing, and this is probably a good option. That way we can track where the > code is from (i.e., com.puppetlabs fact resolutions are part of the core). Yeah, I'm not 100% sure about the specific name "com.puppetlabs" but I think we're definitely on the right track regarding the schema. -- Jeff McCune http://www.puppetlabs.com/ -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev?hl=en.
