Hello! I have this pull request open for puppet-rundeck repo to incorporate a different log4j configuration in our modules. Would you please take a look at it? Thanks. Best regards, Gonzalo

Hi guys, Does puppet-mongodb module support replication configuration? I can make it sets the master node or only arbiter node. I am wondering maybe you have more examples? On this page :

Hi all, We're pleased to announce that version 1.1 of the Resource API has been released yesterday. The Resource API provides a simple way to create new native resources in the form of types and

Hi all, We're pleased to announce that version 1.0 of the Resource API is being launched. The Resource API provides a simple way to create new native resources in the form of types and providers for

Rodrigo, If you don’t mind wiping out all the existing repos, you can tell puppet to recursively manage the /etc/yum.repos.d/ directory, which will remove anything not managed by puppet.

Hi, I'm testing the puppet/yum module on my environment, and on this module I didn't find one option to disable repos that are not managed by Puppet. I wold like to know if there is a way to do it,

Thanks for the input, Eric. With this I think we can justify reducing our support range down to >= 4.10. --dhollinger

sounds good We made that, in my opinion with quite a success, for the migration from 3.X to 4.7.1. We had some discussions about minor updates of a dependency (mostly stdlib and/or puppet). Does that

Hi all, good to see this thread - I put some comments inline. Yeah I think >=4.10.x is a good target - there aren't any earlier 4.x series releases that are getting patches, since 4.10.x is the

I have mixed feelings on this, Just back in January I migrated a Client from 3.6 to 5 ... On one hand support can be maintained at a cost to the maintainers, mean while pinning versions and revving

I'm with Thomas on this, we should always have the same support matrix as Puppet, Inc. Many of our users will be relying on their support lifecycle and for us to stay relevant within Puppet world, we

I agree. I'm fine with supporting 4.10.X until it's EOL (october?). But we should not support anything that's EOL. As a module author we act as a software "vendor" to or users, we're responsible for

Satellite 6.3 just came out and it includes Puppet 4.10.9 so I'd be happy if we continued to support it. Dropping anything older would be fine by me. I think that aligns with the PE versions. Even if

Voxpupuli should generally support puppet versions supported by Puppet Inc. Lifecycle: https://puppet.com/misc/puppet-enterprise-lifecycle Oldest supported PE release: 2016.04 Component list:

Hi everybody, Puppet 5 is available since a long time. Besides many bug fixes it also has support for hiera 5 configs as data-in-modules. Some time ago in the IRC channel we agreed on Puppet 4.7.1 as

Hi Sebastien, thanks for reaching out to us. Can you join our IRC channel #voxpupuli on freenode? That allows us to easily discuss the migration process. Cheers, Tim

Hello voxpupuli! If it's okay, I would like to move my puppet modules to voxpupuli. allknowingdns, bird and dropbear may be good candidates :) https://forge.puppet.com/sbadia Thanks in

On recommendation of a few people on the IRC who are much smarter than I, auto-discovery on the server is the preferred method and NOT using exported resources. Thanks, Brian

I'm getting closer. I was hit by the chicken-egg issue described here: https://github.com/voxpupuli/puppet-zabbix/issues/54 However, now on my Zabbix server I see the following error: Error:

I've looked through the Postgres Database on the PuppetDB server and I am seeing Zabbix_host in the "type" column for the catalog_resources table. I can only assume that the zabbix_host resource in