[Puppet-dev] Feature proposal: "metadata" metaparameter

is best suited for the mailing list. This thread is now open for feedback and discussion. After any initial discussion, updates will be made to the ticket. -- Reid Vandewiele Puppet Solutions Architect -- You received this message because you are subscribed to the Google Groups "Puppet Deve

[Puppet-dev] Re: Has anyone already developed an Elasticsearch backend to Hiera?

Hey Nick, A particular phrase you used caught my attention: "Elasticsearch holds the Hiera config for a number of nodes." There's a lot about putting together the words "elasticsearch" and "hiera backend" that can sound scary if it's done wrong, but I have seen backends built to solve the

Re: [Puppet-dev] lookup from external script

For an abandoned experiment awhile back I went to the trouble of mostly getting an external ruby script working that used Hiera 5 as a library. I don't know that you still want to do this, sounds like there may be other options per the conversation in the thread, but I'll post the following

[Puppet-dev] Re: Hiera Merge

If you're just trying to transform the data in Puppet code and assuming (as Henrik was) that you can't change how the data is stored, something like this might work. # Assuming $was_data is the hash of data from Hiera $common_data = $was_data.filter |$pair| { $pair[0] != 'was_dmgr_data' }

Re: [Puppet-dev] Exists? is called before prefetching

hed methods are not > (yet) called. > > > On Friday, 14 July 2017 22:57:54 UTC+2, Reid Vandewiele wrote: >> >> I haven't dived into the code recently but depending on when prefetching >> happens, it might be possible the Transition type is causing an "early&quo

Re: [Puppet-dev] Exists? is called before prefetching

I haven't dived into the code recently but depending on when prefetching happens, it might be possible the Transition type is causing an "early" invocation of #exists?. This is because Transition invokes a check of the resource it is "prior to", thusly:

Re: [Puppet-dev] send facts once again after catalog applied

On Monday, August 22, 2016 at 12:53:12 AM UTC-7, Craig Dunn wrote: > > See > > # puppet help facts upload > > That sounds like what you want... you may need to tweak your auth.conf > settings too. > I think `puppet facts upload` was removed in Puppet 4, unfortunately. There's this ticket

Re: [Puppet-dev] External facts based on OS

Regardless of the fact that this is on the developer's list, it's worth mentioning that from a use-case perspective it may not actually be necessary to worry about that too much. Even though the entire contents of the directory may be synced (and Michael correct me if I'm wrong about this),

Re: [Puppet-dev] implementation of faces

On Tuesday, September 22, 2015 at 11:43:30 AM UTC-7, Reid Vandewiele wrote: > > > What I know about faces comes from tinkering with them on and off, and > writing one or two over the last couple of years (only one of which I can > find/remember now). I've tinkered with the `pu

Re: [Puppet-dev] implementation of faces

On Tuesday, September 22, 2015 at 9:17:22 AM UTC-7, Luke Kanies wrote: > > On Sep 21, 2015, at 7:52 PM, Corey Osman > wrote: > > > > Hi, > > > > I remember when the puppet 2.7 release came out with support for faces > was all the rage. The faces API seemed pretty

Re: [Puppet-dev] Re: munging the log output from a custom provider

On Fri, Sep 18, 2015 at 9:02 AM Trevor Vaughan wrote: > Hi Corey, > > It's part of the 'property' Object: > https://github.com/puppetlabs/puppet/blob/master/lib/puppet/property.rb#L186 > Related references: http://www.rubydoc.info/gems/puppet/Puppet/Property (same

[Puppet-dev] Re: munging the log output from a custom provider

On Wednesday, September 16, 2015 at 6:19:27 PM UTC-7, Corey Osman wrote: > > > [...] how can I keep the password from showing up in the reports when the > password changes. Basically I don’t want the following to occur. Is there > a way to suppress the logging of this info? Or is there a way

Re: [Puppet-dev] Accessing attribute value of one resource in another resource impleataion

What Michael said about the design is worth considering. If it makes sense to reference another resource instead of a path string (e.g. File[myfile]) and you're just curious about how to do it, there's code that does similar things in the puppetlabs/transition module, as well as in changes

Re: [Puppet-dev] Default environment_timeout preference

The principle of least astonishment is absolutely what we should be targeting. The use of any kind of timer upon whose ticks behavior changes is in inarguable opposition to this, whether it's 10 seconds, 3 minutes, or 15 minutes. However, I think the use of implementation terms like caching in

Re: [Puppet-dev] Default environment_timeout preference

live as opposed to read-on-start. On Fri, Mar 6, 2015 at 11:06 AM, John Bollinger john.bollin...@stjude.org wrote: On Friday, March 6, 2015 at 11:36:03 AM UTC-6, Reid Vandewiele wrote: The principle of least astonishment is absolutely what we should be targeting. The use of any kind of timer

Re: [Puppet-dev] Autorequiring parent directories to the home directory in user resources

On Monday, March 2, 2015 at 7:21:55 AM UTC-8, Trevor Vaughan wrote: HmmOk, how about this: 1) Dangling symlinks are allowed 2) Warnings on dangling symlinks are the default (because you *probably* don't want them) 3) Setting :force = true, disables the warning message (in theory, you

Re: [Puppet-dev] Re: Dealing with transitional states in Puppet

On Mon, Dec 22, 2014 at 9:11 AM, John Bollinger john.bollin...@stjude.org wrote: [...] I went looking for holes to poke in this approach, and didn't find any. I like that it builds on Puppet's core concepts of resources and state, and that it appears to be general enough to be adapted to a

[Puppet-dev] Dealing with transitional states in Puppet

This thread is introducing a simple workaround for an observed limitation in Puppet's ability to automate inelegant but real configuration requirements. The desired outcome is to get feedback on the suitability of the workaround or its approach, how well it fits with Puppet's paradigm, and

Re: [Puppet-dev] Re: Feedback on the behavior of +=, -=, +, and -

On Sunday, August 10, 2014 7:11:11 PM UTC-7, Trevor Vaughan wrote: Yeah, I know that it doesn't actually mutate. But it *feels* like it does, which is the issue. Trevor For this reason I would advocate omission of += and -= from the language. The problem is not that the behavior is

Re: [Puppet-dev] Re: Decision: Near future of resource expressions

On Mon, Aug 4, 2014 at 3:18 PM, Henrik Lindberg henrik.lindb...@cloudsmith.com wrote: So, to summarize: The use of * = as an operator is not liked but the concept of being able to set attributes from a hash is. Unfortunately, it is not possible to directly allow an expression at the position

Re: [Puppet-dev] Re: Decision: Near future of resource expressions

On Tue, Aug 5, 2014 at 4:11 PM, Henrik Lindberg henrik.lindb...@cloudsmith.com wrote: On 2014-05-08 18:24, Andy Parker wrote: My argument against using parenthesis is that parenthesis, are often read as seldom necessary grouping. I believe that most programmers read them as usually only

[Puppet-dev] Re: Decision: Near future of resource expressions

On Sunday, August 3, 2014 4:32:39 PM UTC-7, henrik lindberg wrote: My main objection with create_resources function is that it is not a natural progression from the language. When developing puppet code, you start out with simple resources and use the syntax for creating them. As you

[Puppet-dev] Re: Decision: Near future of resource expressions

Definitely excited to see this stuff moving forwards. On Thursday, July 24, 2014 5:32:13 PM UTC-7, Andy Parker wrote: Henrik took all of the ideas and started trying to work out what we could do and what we couldn't. Those are in a writeup at

[Puppet-dev] Re: RFC2 - Resource Defaults

On Friday, July 11, 2014 7:50:47 PM UTC-7, henrik lindberg wrote: Here we have another problem; variables defined in classes are very different from those defined elsewhere - they are really attributes/parameters of the class. All other variables follow the imperative flow. That has

[Puppet-dev] Making a Puppet custom Type 'optional'...

How about just create a utility define to go with your custom type? E.g. create an rs_tag::conditional define, then use that instead of the rs_tag type directly. You can put the conditional logic in the define and it's about as clean as it gets. You also don't have to muck about with the logic

Re: [Puppet-dev] Making a Puppet custom Type 'optional'...

solution. I'd prefer to do it in the actual provider, but I could see how this is arguably cleaner. Before I do that though, is there no clean way to do this inside the Type or Provider? Matt Wise Sr. Systems Architect Nextdoor.com On Fri, May 23, 2014 at 11:12 AM, Reid Vandewiele r

[Puppet-dev] Re: Help with Composite Namevars

I don't know the right way to do this but I've worked on a couple of composite namevar types at least enough that I've seen that kind of error before. In effect, when using a composite namevar you must manually specify how to extract individual parameters from the resource title. It is assumed