----- Original Message -----
> From: "Christopher Wood" <christopher_w...@pobox.com>
> > Puppet in fact provides three functions functions for lookups: there is
> > also hiera_hash().
> >
> > In any case, you are quite right. Which sort of lookup is intended is
> > an
> > attribute of the data -- part of the definition of each key -- but it is
> > not represented in or alongside the data. Each user of the data somehow
> > has to know. That could be tolerated, inconvenient as it is, except
> > that
> > it is incompatible with automated data binding. This is an issue that
> > has
> > been recognized and acknowledged, though I'm uncertain whether it is
> > actively being addressed.
>
> Could you possibly expound on the "Each user of the data somehow has to know"
> part? I'm having trouble with the notion that people would use puppet
> manifests and hiera data without knowing what's in them.
I can't speak for John but I think I get his meaning, but if I don't, here's my
own opinion ;-)
If a user of a module is reading that module's documentation and parameters, it
seems a bit nasty to assume they user must also go read the Puppet module code
in great detail to find out what type of Hiera call is being used. Passing
data to the module should be simply defined, eg: "this parameter takes an
array" or "this parameter is a comma separated string". For a module to assume
that it can or should attempt to do some sort of deep merging seems overly
complicated and it shifts the focus away from the user providing the right data
to a well written module. Rather than have "classname::merge => true" I would
advocate something like this which puts the user in complete control of the
data reaching it's modules in a correct and easily testable manner:
class 'profile::dns' {
#lookup my DNS data
$hiera_dns_server_array = hiera_array('dns::server')
$common_dns_server = '127.0.0.1'
class { 'resolv':
dns_servers => [ $hiera_dns_server_array, $common_dns_server ]
}
Something like this seems like I'm telling a module *how* to look up my own
data, rather than passing the right data to the module:
class resolv (
$dns_servers_key_name = 'dns_servers',
$dns_servers_key_merge = false,
) {
if ($dns_servers_key_merge) {
$dns_servers = hiera_array($dns_servers_key_name)
} else {
$dns_servers = hiera($dns_servers_key_name)
}
}
class { 'resolv': dns_servers_key_merge => true }
I'd also have to code it to selectively use Hiera or not (some people don't)
and that would get even worse. The second example of module design may be
super awesomely flexible in terms of how I can structure my Hiera data, but it
doesn't fit the direction the community is moving in terms of module design.
-Luke
---
LMAX Exchange, Yellow Building, 1A Nicholas Road, London W11 4AN
http://www.LMAX.com/
---
#1 Fastest Growing Tech Company in UK - Sunday Times Tech Track 100 (2014)
Awards
2015 Best FX Trading Venue - ECN/MTF - WSL Institutional Trading Awards
2014 Best Margin Sector Platform - Profit & Loss Readers' Choice Awards
2014 Best FX Trading Venue - ECN/MTF - WSL Institutional Trading Awards
2014 Best Infrastructure/Technology Initiative - WSL Institutional Trading
Awards
2013 #15 Fastest Growing Tech Company in UK - Sunday Times Tech Track 100
2013 Best Overall Testing Project - The European Software Testing Awards
2013 Best Margin Sector Platform - Profit & Loss Readers' Choice Awards
2013 Best FX Trading Platform - ECN/MTF - WSL Institutional Trading Awards
2013 Best Executing Venue - Forex Magnates Awards
2011 Best Trading System - Financial Sector Technology Awards
2011 Innovative Programming Framework - Oracle Duke's Choice Awards
---
FX and CFDs are leveraged products that can result in
losses exceeding your deposit. They are not suitable
for everyone so please ensure you fully understand
the risks involved.
This message and its attachments are confidential,
may not be disclosed or used by any person other
than the addressee and are intended only for the
named recipient(s). This message is not intended for
any recipient(s) who based on their nationality,
place of business, domicile or for any other
reason, is/are subject to local laws or regulations
which prohibit the provision of such products and
services. This message is subject to the terms at
http://www.lmax.com/pdf/general-disclaimers.pdf
however if you cannot access these, please notify
us by replying to this email and we will send you
the terms. If you are not the intended recipient,
please notify the sender immediately and delete any
copies of this message.
LMAX Exchange is the trading name of LMAX Limited. LMAX
Limited operates a multilateral trading facility. LMAX
Limited is authorised and regulated by the Financial
Conduct Authority (firm registration number 509778)
and is a company registered in England and Wales
(number 6505809).
LMAX Hong Kong Limited is a wholly-owned subsidiary
of LMAX Limited. LMAX Hong Kong is licensed by the
Securities and Futures Commission in Hong Kong to
conduct Type 3 (leveraged foreign exchange trading)
regulated activity with CE Number BDV088.
--
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/1065769342.4311142.1426085346297.JavaMail.zimbra%40lmax.com.
For more options, visit https://groups.google.com/d/optout.
