Hiera auto binding

[DJ]

Hello,

i was reading this doc "http://garylarizza.com/blog/2014/10/24/puppet-workflows-4-using-hiera-in-anger" which says it's not good idea to use Hiera auto binding feature, can you guys suggest if you are using this feature and you have noticed any performance issues or any issues related to not able to find from where data is coming?

Any feedback please.

Regards,
DJ

[DJ]

Sorry correction, it's "Data binding"

[Angel L. Mateo]

El 08/07/15 a las 17:57, DJ escribió:

We are using it without any problem. The only dissapointed thing I've
found is that hiera data is not merged in auto binding calls, but it is
when hiera function is used
(https://docs.puppetlabs.com/hiera/1/puppet.html#priority-only).

--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
http://www.um.es/atica
Tfo: 868887590
Fax: 868888337

[Luke Bigum]

Hi DJ,

In general the more Hiera calls you make the slower your manifests will compile. However, the difference between 1 and 10 is negligible, between 1 and a 1000 you might loose a few seconds. If you use hiera-gpg it will take a little longer (hiera-eyaml should be faster), and if you add more levels of depth it will take a little longer as well. As for the time difference between a data binding hiera lookup and a in-manifest function call, I'd say the difference is pretty much zero.

As for tracing where the data is coming from, it will only be coming from one of three places. The highest priority is an explicit value passed to class parameter:

class { 'foo':
data => "explicit",
}

The second highest priority is a Hiera data binding, and you can use Hiera on the command line to figure that out:

# hiera -c /etc/puppet/hiera.yaml -y /var/lib/puppet/yaml/facts/nodename.domain.yaml environment=production data

And the lowest priority is a class parameter default:

class foo($data = "defaultstring") {...}

--
Luke Bigum

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/44f2c779-5b72-4c2e-870a-477e6cc31935%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
---

LMAX Exchange, Yellow Building, 1A Nicholas Road, London W11 4AN
http://www.LMAX.com/

#1 Fastest Growing Tech Company in the UK - Sunday Times Tech Track 100 (2014)

2015 Best Margin Sector Platform - Profit & Loss Readers' Choice 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 the 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

---

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 following terms (http://lmax.com/pdf/general-disclaimers.pdf), 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.

[Luke Bigum]

Woops, an amendment to look up the 'data' parameter of class 'foo' in Hiera:

# hiera -c /etc/puppet/hiera.yaml -y /var/lib/puppet/yaml/facts/nodename.domain.yaml environment=production foo::data

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1272298899.1210413.1436431109017.JavaMail.zimbra%40lmax.com.

[jcbollinger]

On Wednesday, July 8, 2015 at 10:57:44 AM UTC-5, DJ wrote:

Hello,

i was reading this doc "http://garylarizza.com/blog/2014/10/24/puppet-workflows-4-using-hiera-in-anger" which says it's not good idea to use Hiera auto binding feature, can you guys suggest if you are using this feature and you have noticed any performance issues or any issues related to not able to find from where data is coming?

In principle, you can disable automated data binding altogether in your master's configuration, but I've never heard of anyone actually doing so, and I'm not confident that it wouldn't cause breakage.  Alternatively, you can use the resource-like class declaration syntax and provide a value for every class parameter, for every single class declaration.  Even if that were feasible, it would be poor practice, making your manifest set brittle and difficult to maintain, because if ever you declare a class via the resource-like syntax, that must be the first declaration of that class that Puppet evaluates.  As a general rule, therefore, you should avoid resource-like class declarations, except possibly for classes to -- carefully -- declare private classes of their own modules.  Automated data binding is the feature that rescues parameterized classes -- without it they are a misfeature.

Gary makes good points, however: all those lookups for data binding can be costly in the aggregate.  That cost depends on a lot of factors, among them

• the number of levels in your hierarchy, and the density of data in your higher-priority levels
  
• the number of parameters to which you bind data
• the hiera back-end(s) you use

Note in particular that where you do not provide a value for a class parameter in any way (an extremely common case in most environments), Hiera will look for a value in every single level of your hierarchy before it gives up.

I don't think Gary's point was that you should try to avoid external data bindings altogether.  You should, however, limit the number of levels in your hierarchy, and you should use the most efficient back-ends you can (those that decrypt data for you are more expensive than others; some of them much more expensive).

To the extent that you're at liberty to control the classes and modules you use, consider also favoring those with fewer class parameters.  Module design practice over the last few years has tended to go in the direction of providing large numbers of class parameters, especially on modules' public classes, to make them as adaptable as possible.  Although adaptability is great, in most cases, folks use only a small subset of those parameters in any given catalog, and each parameter has a run-time cost even when it is not used.  Especially when it is not used.


John

[DJ]

Thanks John, Luke for your suggestions.