In general, you're going to want to be cautious about using agent-side functions. It might be simpler to gather information during run time in some cases, but it makes your catalog more black-box and unpredictable. Here are just a couple concerns:
You lose some of the ability to look at the facts and look at the code and know what the outcome will be because the enforcement also depends on the output of some lazy bound agent function. For example, if you have code that uses the $hostname fact, you can validate that the $hostname fact actually resolved to something useful and raise an error if not. You can even fail the compile and enforce the last cached catalog until you can fix it. If that were an agent side function, you won't have any warning before things break. You also make your catalogs less repeatable. For example, if you push out a codebase update and it doesn't work how you want it to, then you can roll back the code, or the hiera data, or the classification as needed. You've got a pretty good expectation that your configuration will return to a working state (with obvious exceptions). You could even revert to that config version a year later. But if you depend on agent side functions, you don't have as strong an expectation because the agent state that might affect the output of the function isn't versioned with the codebase. It's effectively an uncontrolled variable. I'm not trying to discourage you from using agent side functions. In fact, I'm about to do some work on node_encrypt[1] to make it usable as a Deferred function and I'm really excited because that means that on Puppet 6, it will no longer be limited to only File types. But I do want you to be aware of what you're trading it for so you can make an informed decision. The tl;dr is that these concerns essentially boil down to the fact that your configuration state will no longer be fully represented in the catalog. So make sure you account for that when evaluating your options. [1] https://forge.puppet.com/binford2k/node_encrypt On Fri, Aug 31, 2018 at 10:42 AM Henrik Lindberg <henrik.lindb...@puppet.com> wrote: > On 2018-08-31 13:33, bert hajee wrote: > > Lindsy, > > > > Is it just ment for this use case? I can think of other situations where > > in might be vary valuable to fetch a value at run-time on the agent. Now > > whenever we have to get the current state, we need to make a fact. If we > > can make deferred functions for that that would make things much more > > simple. I'm not sure if it the still is "The Puppet way". Like to hear > > any thoughts on that. > > > > Bert > > > > Consider a cached catalog - with Deferred values that cached catalog can > stay the same for as long as it is only the deferred values that need to > change (and that they can be obtained locally or from service). > > Without use of cached catalog, Deferred values are good for things > that must or are much better suited to be computed fresh on the agent. > > - henrik > > > On Friday, 31 August 2018 02:11:52 UTC+2, Lindsey Smith wrote: > > > > Hi all, > > > > We wanted to let you know about an upcoming capability, the Deferred > > type, that is now present in Puppet 6 nightlies and will be part of > > the Puppet 6.0 release. > > > > A longstanding request has been to allow agents to fetch data for > > themselves at catalog application time. One key use case for this is > > getting secrets directly from a store like Conjur, Vault or Consul. > > Without this capability the master has to be in the middle and > > secret values are passed in catalogs around more than is necessary. > > > > The solution in Puppet 6 is the Deferred type. A Deferred value > > describes a function call to be made in the future and when placing > > it in a catalog the agent will replace it with the result of calling > > the wrapped function before it continues with application as normal. > > > > Of course, for the agent to actually fetch data from a keystore the > > function has to exist on the agent side and be loaded during a run. > > In Puppet 6.0, these functions will be downloaded from the master > > via pluginsync from the lib/puppet/functionsdirectory in modules, > > then loaded during an agent run. Though Deferred is intended > > primarily for agents running with a master, it does work in the same > > way with an agent only. > > > > https://gist.github.com/turbodog/06d3fecef403bfefd9c8174ede4d9174 > > <https://gist.github.com/turbodog/06d3fecef403bfefd9c8174ede4d9174 > >has > > more explanation and walks you through a simple Deferred function > > example. Work on this is tracked in PUP-8711 > > <https://tickets.puppetlabs.com/browse/PUP-8711>and updating the > > Puppet specification for Deferred is a work in progress happening > > here: https://github.com/puppetlabs/puppet-specifications/pull/122 > > <https://github.com/puppetlabs/puppet-specifications/pull/122> > > > > If you have other use cases for Deferred we’d love to hear what > > those are. > > > > Lindsey > > > > > > -- > > 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 > > <mailto:puppet-users+unsubscr...@googlegroups.com>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/puppet-users/7c1b7417-abcd-4c17-a237-0681bc9a14bb%40googlegroups.com > > < > https://groups.google.com/d/msgid/puppet-users/7c1b7417-abcd-4c17-a237-0681bc9a14bb%40googlegroups.com?utm_medium=email&utm_source=footer > >. > > For more options, visit https://groups.google.com/d/optout. > > > -- > > Visit my Blog "Puppet on the Edge" > http://puppet-on-the-edge.blogspot.se/ > > -- > 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/pmbugj%2437k%241%40blaine.gmane.org > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CACkW_L7zW1s4e9YJpHjPd0S%3DHevgwdEHbSxi3RQRMQgy-0d3ig%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
