Date   
PDK 1.14.0 now available

Jesse Scott
 

Hello!

The Puppet Developer Experience team is pleased to announce the latest release of the Puppet Development Kit (PDK), version 1.14.0.

A few highlights from this release:

 - `pdk convert` has gained a new `--add-tests` flag which will automatically scaffold out missing unit tests for existing classes and defined types when you convert a module.
- `pdk test unit` now runs in an interactive mode by default, meaning you can use tools like Pry to debug your tests without any `pdk bundle` gymnastics.
- An experimental `pdk console` command has been added which launches an interactive REPL powered by puppet-debugger.
- The experimental `pdk new unit_test` command added in PDK 1.13.0 has been finalized as `pdk new test --unit`. This command is now fully documented.

You can review the full release notes at: https://puppet.com/docs/pdk/1.x/release_notes_pdk.html#release-notes-pdk-x.14

To install or upgrade to this new version, use your platform's package manager (see https://puppet.com/docs/pdk/1.x/pdk_install.html) or download the packages directly for Windows, macOS, and Linux platforms at https://puppet.com/download-puppet-development-kit.

Thanks!

PDK 1.13.0 now available

Jesse Scott
 

Hello!

The Puppet Developer Experience team is pleased to announce the latest release of the Puppet Development Kit (PDK), version 1.13.0.

A few highlights from this release:

 - `pdk convert` will now create missing templated files that were previously only created when generating a new module (e.g. README.md)
- A new `pdk config get` command has been added which lets you inspect the both user-level and module-level configuration values. This is an incremental step in rolling out a robust configuration subsystem for PDK over the course of several releases.
- An experimental `pdk new unit_test` command has been added which allows you to generate basic unit test scaffolding for existing resources


To install or upgrade to this new version, use your platform's package manager (see https://puppet.com/docs/pdk/1.x/pdk_install.html) or download the packages directly for Windows, macOS, and Linux platforms at https://puppet.com/download-puppet-development-kit.

Thanks!

New Ruby Facter RFC

Bogdan Irimie
 

Hello

We value the Puppet community and strive to make it seamlessly for all of you to contribute to open source Puppet projects. With this goal in mind, we propose to rewrite Facter in Ruby and to streamline the interaction with you! Attached is a link to the RFC, feel free to comment directly on the document.

https://docs.google.com/document/d/1u4SDoZUK3AXlgbmhOWgU8zR2RZHAHDxRZ9l-znFKWoY/edit?usp=sharing

Best regards,
Bogdan Irimie

chrony module

wattersm@...
 

Hello,

I am interested in migrating the puppet-chrony module to voxpupuli.  The original project has been unmaintained for a few years and I would like to see this module maintained better.

https://github.com/ringingliberty/puppet-chrony/issues/6

As you can see this issue has been open since 2016.  What would I need to do to get this module set up under voxpupuli?

PDK 1.12.0 now available

Jesse Scott
 

Hello!

The Puppet Developer Experience team is pleased to announce the latest release of the Puppet Development Kit (PDK), version 1.12.0.

A few highlights from this release:

 - PDK will now validate the syntax of Embedded Puppet (.epp) files
 - An experimental `pdk new transport` command has been added
 - The process of installing, upgrading, and uninstalling the PDK package on Windows is now dramatically faster (Somebody buy Glenn Sarti a beverage!)
 - Commands invoked through the `pdk bundle` subcommand can now be interacted with

We have also added packages for RHEL 8, Fedora 30, and Debian 10 with this release.


To install or upgrade to this new version, use your platform's package manager (see https://puppet.com/docs/pdk/1.x/pdk_install.html) or download the packages directly for Windows, macOS, and Linux platforms at https://puppet.com/download-puppet-development-kit.

Thanks!

Re: voxpupuli/puppet-confluence question

 

Hi Scott,
I assume just nobody tried it yet. The module has a couple of tests. Did
you try version 6.15.7? You could also try to add acceptance tests to
prove it works / fails.

Cheers, Tim

On 18.07.19 17:39, Seidl, Scott wrote:
I've been reviewing your code/readme's/issues on voxpupuli/puppet-confluence, and have a question that doesn't seem to be answered... it's a simple one so I hope you can take a minute out of your day to respond. All examples/code have Confluence version 5.7.1... is there a reason for that? Will this code support version 6.15.7?

Scott Seidl
Middleware Tech Lead
Schneider
(920) 592-2163
www.schneider.com<http://www.schneider.com/>
Mail Stop Code: US.GRB.01.03.11

The information contained in this email message may be privileged, confidential and protected from disclosure, and no waiver of any privilege is intended. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender and delete all copies.




Re: New Forge API Endpoints

 

Hi Nik,
sorry for the late reply. I cannot speak for the whole group, but I'm
not aware of anybody of us that has the resources at the moment to patch
blacksmith. Especially since it's currently not broken. Are you able to
provide a pull request? We're happy to review it!

Cheers, Tim

On 15.05.19 23:56, nik.anderson@... wrote:
[Edited Message Follows]
[Reason: Made the formatting a little less awful]

Hello,

The Forge team is getting ready to announce new API endpoints in a blog post (draft below), and we wanted to give you all a heads up beforehand. In short, we've added public endpoints for module management, and authentication through API keys.

We're planning to add support to the puppet_forge gem for the new endpoints in the future. Does it seem like a possibility for the Blacksmith gem to be updated to use the new API key auth? Anything we can do to help with that?

Thanks!

Nik Anderson

Software Engineer

Pronouns: he / his

nik.anderson@...

Puppet ( https://puppet.com ). The shortest path to better software.

DRAFT: New Forge API Endpoints for Automating Module Management

Fully automating the lifecycle of your Puppet module - it's the stuff dreams are made of. Ok, maybe not so much for the general public, but if you're a module developer, this is an exciting prospect! That's why we're pleased to announce a new collection of Forge API endpoints that allow for complete programmatic module management. What does that mean? It's now possible to log in to your Forge account, create an API key, and use that key to publish, delete, or deprecate any of your modules directly through the Forge API.

## Current publishing options Taking a step or two back, we know there are a lot of module developers out there using [Blacksmith]( https://github.com/voxpupuli/puppet-blacksmith ) to publish their modules, so you may be wondering how the new endpoints are an improvement. Blacksmith is a great tool that the Puppet community built in part to fill the gaps in the Forge API. However, some of the prior limitations in the API meant that the publishing flow of the Blacksmith implementation is somewhat less than ideal. For example, since we hadn't yet implemented authentication through API keys, the Blacksmith workflow involves passing a Forge username and password in plain text. This made automated publishing possible, but we’re excited to be able to provide a more standard authentication flow.

## Beyond just publishing Initially we only set out to create a publish endpoint within our v3 namespace for the Forge API. After thinking about the work this would entail and the community needs, we decided it was important to add endpoints for other essential module management tasks as well, namely deletion and deprecation. We ended up adding the following endpoints:
* `POST /v3/releases`
* `DELETE /v3/releases/<release-slug>`
* `DELETE /v3/modules/<module-slug>`
* `PATCH /v3/modules/<module-slug>` (used for module deprecation)

With that, it's possible to automate the entire module lifecycle. Here's an outline of what those steps might look like using `curl`:

To publish a new module release using curl, you can run this command:
~~~ $ curl -D- --request 'POST' ' https://forgeapi.puppet.com/v3/releases ' \ -F file=@nkanderson-testmodule-0. 1.0.tar.gz \ -H 'Authorization: Bearer <REPLACE WITH YOUR API KEY>' ~~~

And to mark a module release as deleted:
~~~ $ curl -D- --request DELETE \ ' https://forgeapi.puppet.com/v3/releases/nkanderson-testmodule-0.1.0?reason=buggy+release ' \ -H 'Authorization: Bearer <REPLACE WITH YOUR API KEY>' ~~~

Deleting the entire module will mark all individual releases as deleted, effectively removing it from the Forge web interface:
~~~ $ curl -D- --request DELETE \ ' https://forgeapi.puppet.com/v3/modules/nkanderson-testmodule?reason=buggy+module ' \ -H 'Authorization: Bearer <REPLACE WITH YOUR API KEY>' ~~~

To mark a module as deprecated, use the PATCH method. Note that json data is required to specify the deprecate action. Optional parameters include the reason for deprecation and the slug for a replacement module.
~~~ $ curl -D- --request PATCH ' https://forgeapi.puppet.com/v3/modules/nkanderson-testmodule ' \ -d '{"action": "deprecate", "params": {"reason": "No longer maintained", "replacement_slug": "puppetlabs-mysql"} }' \ -H 'Content-Type: application/json' -H 'Authorization: Bearer <REPLACE WITH YOUR API KEY>' ~~~

## Bonus: Updated docs! Once we got into the documentation phase for these new endpoints, we realized our Forge API docs could use a little love. So another improvement we made along the way was to update our docs framework. Beyond just a fresh coat of paint, the new docs are clearer and easier to navigate, with added descriptions for a handful of parameters that hadn’t previously surfaced from implementation to the docs. (Screenshot of New Forge API docs)

Want to try it out? Log in to your Forge account, navigate to your user profile page (hint: click your name in the upper right), and on that page you'll see an option to create a new key. Once you've created a key, you're all set to hit the ground running with automating your module management.



voxpupuli/puppet-confluence question

Seidl, Scott <SeidlS@...>
 

I’ve been reviewing your code/readme’s/issues on voxpupuli/puppet-confluence, and have a question that doesn’t seem to be answered… it’s a simple one so I hope you can take a minute out of your day to respond.  All examples/code have Confluence version 5.7.1… is there a reason for that?  Will this code support version 6.15.7?

 

Scott Seidl

Middleware Tech Lead

Schneider

(920) 592-2163

www.schneider.com

Mail Stop Code:  US.GRB.01.03.11

 

The information contained in this email message may be privileged, confidential and protected from disclosure, and no waiver of any privilege is intended. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender and delete all copies.

 

PDK 1.11.1 now available

Jesse Scott
 

Hello!

We’re pleased to announce the latest release of Puppet Development Kit (PDK), version 1.11.1.

This release contains fixes for two bugs that were impacting the usage of PDK in Continuous Integration (CI) environments such as Travis CI:
  • PDK will now use environment variables to recognize common CI environments and always treat those environments as "noninteractive" which will bypass (among other things) the recently added analytics opt-out prompt.
  • The analytics opt-out prompt will now always be skipped if the PDK_DISABLE_ANALYTICS environment variable is set.
To learn more about these issues and the fixes implemented, please see the PDK release notes: https://puppet.com/docs/pdk/1.x/release_notes_pdk.html#release-notes-pdk-x.11.1

To upgrade to this new version, download it for Windows, macOS, and Linux platforms at https://puppet.com/download-puppet-development-kit. For Yum or Apt-based Linux users, you can install PDK via the Puppet Linux repos or using yum or apt on the Linux command line. macOS users can also install and upgrade via Homebrew: https://github.com/puppetlabs/homebrew-puppet#pdk

Thanks!

PDK 1.11.0 now available

Jesse Scott
 

Hello Vox Pupuli!

We’re pleased to announce the latest release of Puppet Development Kit (PDK), version 1.11.0.

This release contains a variety of incremental improvements and bug fixes. You can review the full release notes at: https://puppet.com/docs/pdk/1.x/release_notes_pdk.html#release-notes-pdk-x.11

Additionally, PDK now gathers anonymous data about your PDK usage. This data helps us understand how you use PDK and how we can improve it. You can opt out of data collection at any time. For details about what data is collected, how your data is anonymized, and how to opt out, see the documentation for PDK analytics: https://puppet.com/docs/pdk/1.x/pdk_install.html#pdk-analytics

To upgrade to this new version, download it for Windows, macOS, and Linux platforms at https://puppet.com/download-puppet-development-kit. For Yum or Apt-based Linux users, you can install PDK via the Puppet Linux repos or using yum or apt on the Linux command line.

Thanks!

Adding analytics to PDK

Jesse Scott
 

TL;DR: We are adding anonymous usage reporting to PDK in the next release, very similar to what is in Bolt. PDK will ask you on first use if you want to opt-out. You can also opt-out later by editing a config file or setting an environment variable.

Hello everyone,

The PDK team would like to let you know that the next version of PDK will include some basic usage reporting/analytics code to help us measure overall adoption and better understand the ways users are interacting with PDK.

All reporting is anonymous and we redact anything that could be considered sensitive before it leaves your system.

Furthermore, to help everyone better understand the shape and scale of the Puppet content developer community it is our intent to make aggregate usage data available on a public dashboard in the future.

Below is a draft of the updated PDK documentation that describes what data is collected and reported as well as how to opt out. One thing that the draft documentation currently does not reflect is that you can also opt out by setting the environment variable "PDK_DISABLE_ANALYTICS=true".

Please let us know if you have any questions or concerns.

Thanks!

-- The PDK Team


PDK data collection

PDK collects usage data to help us understand how it's being used and how we can improve it. You can opt out of data collection at any time; see the section below about opting out.

We collect these values for every analytics event:
  • A random non-identifying user ID. This ID is shared with Bolt analytics, if you've installed Bolt and enabled analytics.
  • PDK installation method (package or gem).
  • Version of PDK.
  • Operating system and version.
For every successful command line invocation of PDK, we collect:
  • The PDK command executed, such as "pdk new module" or "pdk validate".
  • Anonymised command options and arguments.
  • The version of Ruby used to execute the PDK command.
  • The output formats for the command.
  • PDK_* environment variables and their values, if set.
  • Whether a template repository, if used, is default or custom — we do not record the path to the template repo itself.
  • If the default template repo is used, we collect events for each file rendered, recording whether the file is unmanaged, deleted, customized, or default. For customized files, we do not record what changed, only that it was changed in the .sync.yml file.
Note: All arguments and non-Boolean option values, except --puppet-version and --pe-version are redacted in our collected data.

Invalid commands are submitted as a distinct analytics events with the arguments and option values redacted.

To see the data PDK collects, add --debug to a command.

We test the analytics calls strictly to ensure that no unexpected data is accidentally passed in.

Opting out of PDK data collection

The first time you run PDK, it asks you if you want to opt out of data collection. To opt out of data collection after that, edit the analytics.yml file, setting the disabled key to true.

The location of this configuration file depends on your operating system and configuration:
  • For most *nix systems, where the $XDG_CONFIG_HOME variable is set: ${XDG_CONFIG_HOME}/puppet/analytics.yml
  • For most macOS systems, where the $XDG_CONFIG_HOME variable is not set: ~/.config/puppet/analytics.yml
  • For Windows: %LOCALAPPDATA%/puppet/analytics.yml

Re: Deprecate voxpupuli/nscd in favor of ghoneycutt/nscd

Steve Traylen
 

The VP module is probably more modern currently. It's mostly missing support for other OSes and exposing every variable . Adding those things is probably similar to modernising GC module. 
Have been planning to add the missing stuff to VP one . Was stuck behind a MR that has been there for ages.

I say we just merge the functionality of the two modules. Nothing is wrong in either module.

On Tue, 11 Jun 2019, 19:10 James Powis, <powisj@...> wrote:
My largest concern comes from deprecating a community supported module in favor of a single individual supported module. Humans die easily, groups die less easily.

Also Vox really needs some level of guidelines for how a module leaves Vox and / or is deprecated in favor of something else.

Thanks,

James R. Powis


On Mon, Jun 10, 2019 at 1:05 PM Garrett Honeycutt <gh@...> wrote:
Hello,

Would like to propose deprecating voxpupuli/nscd[1] in favor of
ghoneycutt/nscd[2].

My version has all the functionality present in VP's version and is
feature complete to the documentation on all supported platforms. VP's
supports EL 6 and 7 and mine supports EL 5-7, Amazon Linux, Debian 6,
Solaris 10, Suse 10-12, 15, OpenSuse 13 and Ubuntu 12. They are both
under the Apache v2 license.

What my module is missing is strong data types, puppet-strings
documentation (though every parameter is already documented), hiera data
in module and acceptance tests. It does have comprehensive spec tests
and is widely used in production.

[1] - https://github.com/voxpupuli/puppet-nscd
[2] - https://github.com/ghoneycutt/puppet-module-nscd

Best regards,
-g

--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658



Re: Deprecate voxpupuli/nscd in favor of ghoneycutt/nscd

James Powis
 

My largest concern comes from deprecating a community supported module in favor of a single individual supported module. Humans die easily, groups die less easily.

Also Vox really needs some level of guidelines for how a module leaves Vox and / or is deprecated in favor of something else.

Thanks,

James R. Powis


On Mon, Jun 10, 2019 at 1:05 PM Garrett Honeycutt <gh@...> wrote:
Hello,

Would like to propose deprecating voxpupuli/nscd[1] in favor of
ghoneycutt/nscd[2].

My version has all the functionality present in VP's version and is
feature complete to the documentation on all supported platforms. VP's
supports EL 6 and 7 and mine supports EL 5-7, Amazon Linux, Debian 6,
Solaris 10, Suse 10-12, 15, OpenSuse 13 and Ubuntu 12. They are both
under the Apache v2 license.

What my module is missing is strong data types, puppet-strings
documentation (though every parameter is already documented), hiera data
in module and acceptance tests. It does have comprehensive spec tests
and is widely used in production.

[1] - https://github.com/voxpupuli/puppet-nscd
[2] - https://github.com/ghoneycutt/puppet-module-nscd

Best regards,
-g

--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658



Deprecate voxpupuli/nscd in favor of ghoneycutt/nscd

Garrett Honeycutt
 

Hello,

Would like to propose deprecating voxpupuli/nscd[1] in favor of
ghoneycutt/nscd[2].

My version has all the functionality present in VP's version and is
feature complete to the documentation on all supported platforms. VP's
supports EL 6 and 7 and mine supports EL 5-7, Amazon Linux, Debian 6,
Solaris 10, Suse 10-12, 15, OpenSuse 13 and Ubuntu 12. They are both
under the Apache v2 license.

What my module is missing is strong data types, puppet-strings
documentation (though every parameter is already documented), hiera data
in module and acceptance tests. It does have comprehensive spec tests
and is widely used in production.

[1] - https://github.com/voxpupuli/puppet-nscd
[2] - https://github.com/ghoneycutt/puppet-module-nscd

Best regards,
-g

--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

New Forge API Endpoints

Nik Anderson
 
Edited

Hello,
 
The Forge team is getting ready to announce new API endpoints in a blog post (draft below), and we wanted to give you all a heads up beforehand. In short, we've added public endpoints for module management, and authentication through API keys.
 
We're planning to add support to the puppet_forge gem for the new endpoints in the future. Does it seem like a possibility for the Blacksmith gem to be updated to use the new API key auth? Anything we can do to help with that?
 
Thanks!
 

Nik Anderson

Software Engineer

Pronouns: he / his

nik.anderson@...

Puppet. The shortest path to better software.
 
 
DRAFT: New Forge API Endpoints for Automating Module Management
 
Fully automating the lifecycle of your Puppet module - it's the stuff dreams are made of. Ok, maybe not so much for the general public, but if you're a module developer, this is an exciting prospect! That's why we're pleased to announce a new collection of Forge API endpoints that allow for complete programmatic module management. What does that mean? It's now possible to log in to your Forge account, create an API key, and use that key to publish, delete, or deprecate any of your modules directly through the Forge API.

## Current publishing options Taking a step or two back, we know there are a lot of module developers out there using [Blacksmith](
https://github.com/voxpupuli/puppet-blacksmith) to publish their modules, so you may be wondering how the new endpoints are an improvement. Blacksmith is a great tool that the Puppet community built in part to fill the gaps in the Forge API. However, some of the prior limitations in the API meant that the publishing flow of the Blacksmith implementation is somewhat less than ideal. For example, since we hadn't yet implemented authentication through API keys, the Blacksmith workflow involves passing a Forge username and password in plain text. This made automated publishing possible, but we’re excited to be able to provide a more standard authentication flow.

## Beyond just publishing Initially we only set out to create a publish endpoint within our v3 namespace for the Forge API. After thinking about the work this would entail and the community needs, we decided it was important to add endpoints for other essential module management tasks as well, namely deletion and deprecation. We ended up adding the following endpoints:
* `POST /v3/releases`
* `DELETE /v3/releases/<release-slug>`
* `DELETE /v3/modules/<module-slug>`
* `PATCH /v3/modules/<module-slug>` (used for module deprecation)

With that, it's possible to automate the entire module lifecycle. Here's an outline of what those steps might look like using `curl`:

To publish a new module release using curl, you can run this command:
~~~ $ curl -D- --request 'POST' '
https://forgeapi.puppet.com/v3/releases' \ -F file=@nkanderson-testmodule-0.1.0.tar.gz \ -H 'Authorization: Bearer <REPLACE WITH YOUR API KEY>' ~~~

And to mark a module release as deleted:
~~~ $ curl -D- --request DELETE \ '
https://forgeapi.puppet.com/v3/releases/nkanderson-testmodule-0.1.0?reason=buggy+release' \ -H 'Authorization: Bearer <REPLACE WITH YOUR API KEY>' ~~~

Deleting the entire module will mark all individual releases as deleted, effectively removing it from the Forge web interface:
~~~ $ curl -D- --request DELETE \ '
https://forgeapi.puppet.com/v3/modules/nkanderson-testmodule?reason=buggy+module' \ -H 'Authorization: Bearer <REPLACE WITH YOUR API KEY>' ~~~

To mark a module as deprecated, use the PATCH method. Note that json data is required to specify the deprecate action. Optional parameters include the reason for deprecation and the slug for a replacement module.
~~~ $ curl -D- --request PATCH '
https://forgeapi.puppet.com/v3/modules/nkanderson-testmodule' \ -d '{"action": "deprecate", "params": {"reason": "No longer maintained", "replacement_slug": "puppetlabs-mysql"} }' \ -H 'Content-Type: application/json' -H 'Authorization: Bearer <REPLACE WITH YOUR API KEY>' ~~~

## Bonus: Updated docs! Once we got into the documentation phase for these new endpoints, we realized our Forge API docs could use a little love. So another improvement we made along the way was to update our docs framework. Beyond just a fresh coat of paint, the new docs are clearer and easier to navigate, with added descriptions for a handful of parameters that hadn’t previously surfaced from implementation to the docs. (Screenshot of New Forge API docs)

Want to try it out? Log in to your Forge account, navigate to your user profile page (hint: click your name in the upper right), and on that page you'll see an option to create a new key. Once you've created a key, you're all set to hit the ground running with automating your module management.

Litmus

Davin Hanlon
 

Hi everyone,


The modules team at Puppet have been working on a new project called Litmus. It is a framework for acceptance testing Puppet modules. We are in the process of testing this out with our supported modules and MOTD is the first module that’s been converted - see the PR here.


Litmus provides:

  • An interactive workflow, allowing you to provision nodes, install the agent, install the module and run acceptance tests.

  • An extensible framework, allowing additional provisioners or test frameworks to be added.

As part of adopting Litmus we are performing more acceptance testing in Travis and Appveyor, reducing our dependence on internal pipelines. This will means that contributors will get more extensive feedback when they submit pull requests on modules that use Litmus for acceptance testing.

We encourage you to have a look at the Litmus wiki here. It has a guide for working with MOTD, and also guides on how to convert existing modules to use Limus for acceptance tests. We will be migrating Puppet supported modules to use Litmus over the coming weeks and months. This is the first iteration of Litmus, we plan to continue to add functionality over the coming months to solve more complex use cases and with the goal of being the default acceptance tool for Puppet modules.


If you have any questions or queries please raise issues on the GitHub repo and we’ll do our best to respond promptly.


Thanks.




New Blogpost: Setting up Vim for modern Puppet development

 

Hey people!
One of our members, dhollinger, wrote a good article about setting up
Vim for modern Puppet development. Check it out at:
https://voxpupuli.org/blog/2019/04/08/puppet-lsp-vim/

Do you have a good idea for another blog post or want to write one? Let
us know or provide a PR:
https://github.com/voxpupuli/voxpupuli.github.io/tree/master/_posts


Cheers, Tim

Re: GitHub Vox Pupuli Community

 

Hi Tommy,
thanks for asking! Did you already work on one of our repositories? Are
you interested in any particular project?

Cheers,
Tim

On 3/13/19 7:18 AM, via Groups.Io wrote:
Hey,

May I join your GitHub Vox Pupuli Puppet module and tooling community: https://github.com/voxpupuli ?

I’m a network engineer working on the DevOps approach to network engineering, with a focus on Puppet and automation.

Cheers,
Tommy
GitHub Username: techietommy
https://github.com/techietommy



GitHub Vox Pupuli Community

Tommy Chong <techietommy@...>
 

Hey,

May I join your GitHub Vox Pupuli Puppet module and tooling community: https://github.com/voxpupuli ?

I’m a network engineer working on the DevOps approach to network engineering, with a focus on Puppet and automation.

Cheers,
Tommy
GitHub Username: techietommy
https://github.com/techietommy

Splunk 7.2

David Decker <deckercdavid@...>
 

Looking for information about splunk 7.2.4 and puppet I read a bit back that puppet was not working well with the 7.1 with the username/password creation.  

Just wanted to see if this is an issue and if it's been resolved. 

Thanks
David