This sounds great. My only concern is that I don’t see tests mentioned in the
example. Will rspec-puppet be updated at the same time so that we can test
deferred functions out of the gate? If so, I’d love to see what that looks
like, in case we have any comments on that. Mocking some things
On 2018-08-31 20:23, Peter K wrote:
I'm getting this error when I try and create a user on osx:
'''Error: Failed to apply catalog: undefined method `each' for
nil:NilClass'''
My code looks like this:
''' class fakeadmin2 {
user { 'fakeadmin2':
name => 'fakeadmin2',
ensure
On 2018-08-31 20:12, Ben Ford wrote:
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
The puppet agent is on a mac with 10.13.4.
On Friday, August 31, 2018 at 2:23:03 PM UTC-4, Peter K wrote:
>
> I'm getting this error when I try and create a user on osx:
> '''Error: Failed to apply catalog: undefined method `each' for
> nil:NilClass'''
>
> My code looks like this:
>
> ''' class
I'm getting this error when I try and create a user on osx:
'''Error: Failed to apply catalog: undefined method `each' for
nil:NilClass'''
My code looks like this:
''' class fakeadmin2 {
user { 'fakeadmin2':
name=> 'fakeadmin2',
ensure => 'present',
uid => '504',
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
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
On 2018-08-31 15:12, R.I.Pienaar wrote:
On Fri, 31 Aug 2018, at 15:03, Chadwick Banning wrote:
Would it be safe to consider this in a general context i.e. as enabling
agent-side function execution?
I dont think so - for general function calls to be usable you want to get the
value and then
On 2018-08-31 18:28, R.I.Pienaar wrote:
On Fri, 31 Aug 2018, at 17:41, Chadwick Banning wrote:
So for this example, there are some sort of limitations as to what the
'vault_lookup' function is able to do internally? I had just assumed that
as long as the function returned a simple value, what
In general, I would agree. But enterprises often have limiting factors that
make rewriting/redesign very difficult. Also, IMHO newer Puppet users can
understand function creation a lot easier than building out custom
resources and types.
Facts work well for a lot of use cases, but as mentioned
On Fri, 31 Aug 2018, at 17:41, Chadwick Banning wrote:
> So for this example, there are some sort of limitations as to what the
> 'vault_lookup' function is able to do internally? I had just assumed that
> as long as the function returned a simple value, what the function does
> internally was
On Friday, 31 August 2018 16:41:34 UTC+1, Chadwick Banning wrote:
>
> So for this example, there are some sort of limitations as to what the
> 'vault_lookup' function is able to do internally? I had just assumed that
> as long as the function returned a simple value, what the function does
>
Couldn't agree more Bert! I would love to be able to query live system
information during the run, instead of having to rely on facts for this in
all use cases.
For example, I recently had a case where I wanted to make the code more
resilient by using a Windows environment variable instead of
I would love to be able to query live system information during the run,
instead of having to rely on facts for this in all use cases.
For example, I recently had a case where I wanted to make the code more
resilient by using a Windows environment variable instead of a hardcoded
path for
So for this example, there are some sort of limitations as to what the
'vault_lookup' function is able to do internally? I had just assumed that
as long as the function returned a simple value, what the function does
internally was open.
As an example, could Deferred be used to read and extract a
On Friday, August 31, 2018 at 4:33:02 AM UTC-7, 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
On Fri, 31 Aug 2018, at 15:03, Chadwick Banning wrote:
> Would it be safe to consider this in a general context i.e. as enabling
> agent-side function execution?
I dont think so - for general function calls to be usable you want to get the
value and then do some conditional logic on it. or
Would it be safe to consider this in a general context i.e. as enabling
agent-side function execution?
On Thursday, August 30, 2018 at 8:11:52 PM UTC-4, Lindsey Smith wrote:
>
> Hi all,
>
> We wanted to let you know about an upcoming capability, the Deferred type,
> that is now present in
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
19 matches
Mail list logo
