i/Annotation
*~ fin ~*
The corresponding ticket for this proposal is
https://tickets.puppetlabs.com/browse/PUP-10491.
Initial discussion 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.
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 "con
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
lin
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' }
$hash1
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&q
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:
https://github.com/puppetlabs/puppetlabs
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 curre
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), whe
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 th
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 slick as its a pluggable
>
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 thing, the rdoc
view)
https://
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 t
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 pe
live as opposed to read-on-start.
On Fri, Mar 6, 2015 at 11:06 AM, John Bollinger
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 a
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"
i
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
On Mon, Dec 22, 2014 at 9:11 AM, John Bollinger
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 wide variety of
> s
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 whet
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 i
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 us
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 po
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
> y
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
> https://docs.google.com/a/puppetlabs.com/doc
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
if I
> can't come up with another 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
>
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 a
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 assume
27 matches
Mail list logo