Date   
Puppet module autofs assistance

J so <jsogood@...>
 

Hello,

I been using a previous version of your module for some time.  I recently upgraded to 5.0.0 and have had little success formatting the data to even get a single Puppet run.  I am using Foreman 1.18RC1 with Puppet 5.3.3.  

'mapfiles' param:

home:
  path: '/etc/auto.home'
  mappings:
  - key: '*'
  - options: 'rw'
  - fs: nfs-1:/home/&

mounts param:

home:
  ensure: present
  mount: '/home'
  mapfile: '/etc/auto.home'
  options: '--timeout=300'

Puppet errors:

Could not retrieve catalog...  ...Autofs::Mapfile[home]:
parameter 'mappings' index 0 expects a value for key 'fs'
parameter 'mappings' index 1 expects a value for key 'key'
parameter 'mappings' index 1 expects a value for key 'fs'
parameter 'mappings' index 0 expects a value for key 'key'

Error: no parameter named 'format' (file:  .../concat/manifests/init.pp, line 94) on Concat_file[/etc/auto.master] ...


Hopefully this is enough to allow an opportunity to be pointed in the right direction.  I have been bashing my brain against this for some time now.

Thanks in advance!


--
Justin Soppe

 


[ANN] Resource API v1.4.0 Release

David Schmitt
 

Hi folks,

We're pleased to announce that version 1.4.0 of the Resource API is being released today.

The Resource API provides a simple way to create new native resources in the form of types and providers for Puppet. It is provided as a Ruby gem to be referenced within modules. Support for it has been included as an experimental feature in version 1.4 of the Puppet Development Kit (pdk new provider). Use the resource_api module or the puppet 6 nightly packages to deploy it in your infrastructure.

The new release of the Resource API provides the following enhancements:

  • Purging with resources { 'your_type': purge => true } works now for Resource API types. This allows users of your type to clean up everything that is not managed by the current catalog. (PDK-1007)
  • Enhanced validation for developers: the Resource API now checks return values from get() against the type's definition. This aids in finding bugs in the provider itself earlier and can be turned on and off through puppet's --strict setting. (PDK-917)
  • To make device-based code better re-usable, the SimpleDevice class now also takes configuration as a Hash. (#96)

The new release also contains the following notable bugfixes:

  • Exception handling during batch operations has been fixed to show all stack traces for better debugability (#101)
  • Empty (nil) attribute values are not printed from puppet resource (#100)
  • Improved error messages on data type errors in the type definition (PDK-996)

See the CHANGELOG for a full list of changes

We encourage all module developers to review the Resource API and use it when creating types and providers. For reference, there is an example of its usage in a branch of the apt module.

Please let us know of your experiences with the Resource API, either here, on Slack (#forge-modules), or on the github repo.

Thanks, David Schmitt & David Armstrong

--
--

Vox Pupuli Privacy Policy

David Hollinger
 

Due to the nature of the EU's General Data Protection Regulation (GDPR) Rules, the community is required to maintain a Privacy Policy that is compliant with the new rules. This PR is the living draft of that new Privacy Policy and we want to give the community time to review it before we publish it officially.

The PR can be found here: https://github.com/voxpupuli/voxpupuli.github.io/pull/141

It is incredibly important that as many community members as possible contribute their voice to the discussion before we take the new Policy live.

Thanks!

David Hollinger

[ANN] Resource API v1.3.0 Release

David Armstrong
 

Hi all,

We're pleased to announce that version 1.3.0 of the Resource API is being released today.

The Resource API provides a simple way to create new native resources in the form of types and providers for Puppet. It is provided as a Ruby gem to be referenced within modules. Support for it has been included as an experimental feature in version 1.4 of the Puppet Development Kit (pdk new provider). Use the resource_api module or the puppet 6 nightly packages to deploy it in your infrastructure.

The new release of the Resource API provides the following enhancements:

The new release also contains the following notable bugfixes:

  • Additional checks added for reserved attribute names.
  • `puppet apply` will now work correctly when accessing an absent resource.
  • Mungify will no longer affect workflows outside of `puppet resource`.

See the CHANGELOG for a full list of changes

We encourage all module developers to review the Resource API and use it when creating types and providers. For reference, there is an example of its usage in a branch of the apt module.

Please let us know of your experiences with the Resource API, either here, on Slack (#forge-modules), or on the github repo.

Thanks, 


David Armstrong



--
David Armstrong
Software Engineer

[ANN] Resource API v1.2 Release

David Schmitt
 

Hi all,

We're pleased to announce that version 1.2 of the Resource API is being released today.

The Resource API provides a simple way to create new native resources in the form of types and providers for Puppet. It is provided as a Ruby gem to be referenced within modules. Support for it has been included as an experimental feature in version 1.4 of the Puppet Development Kit (pdk new provider). Use the resource_api module or the puppet 6 nightly packages to deploy it in your infrastructure.

The new release of the Resource API provides the following enhancements:

The new release also contains the following notable bugfixes:
  • ensure values are now passed to puppet as symbols. While the Enum data type is a string, puppet expects symbols for ensure to activate its special handling for ensure. This version of the Resource API restores the symbolization behaviour on the puppet side, without disturbing providers expecting a string.
  • The Resource API no longer validates attribute values on resources that should be absent. This matches existing puppet behaviour, and is necessary to be able to delete resources without having to specify a (otherwise) valid configuration.

See the CHANGELOG for a full list of changes

We encourage all module developers to review the Resource API and use it when creating types and providers. For reference, there is an example of its usage in a branch of the apt module.

Please let us know of your experiences with the Resource API, either here, on Slack (#forge-modules), or on the github repo.

Thanks, David
--

puppet-rundeck repo PR

Gonzalo Foligna <gonzalo.foligna@...>
 

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 Foligna
System Adminstrator
Vix, Inc.
p: (305) 476-1574
m: (305) 790-8269
w: www.vix.com

Puppet mongodb module.

Maksym Nebot <nebot.max@...>
 

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?

I found info about :
master
Set to true to configure the current instance to act as master instance in a replication configuration. Default: False Note: deprecated – use replica sets

But I cant find any info hot to define node as master node.
I have tried to define the Arbiter those params in the hiera:

mongodb::server::replset: 'rs0'
mongodb::server::replset_members:
mongodb::server::replset_arbiter: '10.10.10.183:27017'

but it does not work.

-- 
Max Nebot

[ANN] Resource API v1.1 Release

David Schmitt
 

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 providers for Puppet. It is provided as a Ruby gem to be referenced within modules. Support for it has been included as an experimental feature in version 1.4 of the Puppet Development Kit (pdk new provider). Use the resource_api module to deploy it in your infrastructure.

The new release of the Resource API provides the following enhancements:

  • Arrays are now fully supported as data types (v1.1.0)
  • Read only and init only attributes have that status now fully enforced (v1.0.3)

The new release also contains the following notable bugfixes:

  • PDK-911: handling of ensure values changed to use strings: Previous to v1.0.3, in some cases ensure values of 'absent' and 'present' would be transformed to ruby symbols before passing it on to the provider. This behavior was inconsistent with both puppet and other Enums in the Resource API, that would always use strings. Providers now need to return and accept the strings 'absent' and 'present' instead of the :absent and :present symbols.
  • PDK-919: Boolean attributes now work in all cases: In some cases puppet can ignore true boolean values. The Resource API now works around the issue in a transparent way that requires no change to providers.

See the CHANGELOG for a full list of changes.

We encourage all module developers to review the Resource API and use it when creating types and providers. For reference, there is an example of its usage in a branch of the apt module.

Please let us know of your experiences with the Resource API, either here, on Slack (#forge-modules), or on the github repo.


Thanks,

David

--

Announcement: Resource API v1.0 release

David Schmitt
 

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 Puppet. It is provided as a Ruby gem to be referenced within modules. Support for it has been included as an experimental feature in version 1.4 of the Puppet Development Kit (`pdk new provider`).


The Resource API provides the following functionality:


  • Simple type and provider definition.

  • Use Puppet 4+ data types.

  • Canonicalize, simple_get_filter, and remote_resource features.

  • Logging facilities.

  • New providers are compatible with all puppet commands:

    • puppet apply

    • puppet resource

    • puppet agent

    • puppet device (if applicable)


To ease adoption of the Resource API there is a module on the Forge to install it in your Puppet Server or Puppet Agent. The Resource API gem must be installed in order to use modules that have types and providers created using the Resource API. In the future we are planning to bundle the Resource API with the Puppet platform.


We encourage all module developers to review the Resource API and use it when creating modules that have types and providers. For reference, there is an example of its usage in a branch of the apt module.


Please let us know of your experiences with the Resource API.

Cheers, David

--

Re: Question about Yum Puppet module

daryl wiest
 

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.


On Mar 22, 2018, at 12:16 PM, Rodrigo de Lima Silva <rodrigodlima@...> wrote:

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, like this:

   class { 'yum':
    repos => {
      "redhat" => {
        "enabled" => '1'
      }
    },
    defaults => { enabled => '0' },
   }

Thanks!

--
Rodrigo Lima  - rodrigodlima[at]gmail[dot]com

Question about Yum Puppet module

Rodrigo de Lima Silva <rodrigodlima@...>
 

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, like this:

   class { 'yum':
    repos => {
      "redhat" => {
        "enabled" => '1'
      }
    },
    defaults => { enabled => '0' },
   }

Thanks!

--
Rodrigo Lima  - rodrigodlima[at]gmail[dot]com

Re: Get rid of Puppet4?

David Hollinger
 

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 'last of the line' before 5. It is a very short step from 4.10.x to 5 too, so i'd suggest being generous about dropping 4.x compatibility unless you *know* a module uses some 5.x-only construct.

This is in no way an official Puppet Inc statement but I suspect there will be a longer tail to 4.10 than just October 2018, given its inclusion in Satellite and widespread use out in the world.
Thanks for the input, Eric. With this I think we can justify reducing our support range down to >= 4.10.

--dhollinger

Re: Get rid of Puppet4?

 

On 21.03.2018 19:32, Eric Sorenson wrote:
Hi all, good to see this thread - I put some comments inline.

On Mar 21, 2018, at 2:45 AM, Tim Meusel <@bastelfreak> wrote:
On 03/21/2018 10:39 AM, Ewoud Kohl van Wijngaarden wrote:
On Wed, Mar 21, 2018 at 09:58:20AM +0100, Thomas Mueller wrote:
On 03/21/2018 09:50 AM, Tim Meusel wrote:
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 our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
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:
https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x
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.
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 them. We should
not encourage them to run outdated software. We should also point out
that people are not required to update their local module version, just
because we released a newer version.

I wrote that many times in issues and pull requests. I just realized
that our Puppet 4.7.1 is now EOL as well and we should maybe bump the
puppet version in all modules to at least 4.10.X? No matter if they use
data-in-modules or not.
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 'last of the line' before 5. It is a very short step from 4.10.x to 5 too, so i'd suggest being generous about dropping 4.x compatibility unless you *know* a module uses some 5.x-only construct.
sounds good

This is in no way an official Puppet Inc statement but I suspect there will be a longer tail to 4.10 than just October 2018, given its inclusion in Satellite and widespread use out in the world.


But I don't think you can create a policy that fits for every
voxpupuli module. For some modules it maybe makes sense to support
older puppet and for others not.
Even if it's not a policy, some guidelines are good to have.
Does it work to make a new major version of the module that has tighter compatibility constraints? I think we talked about this as a community in the 3.x->4.x timeframe but I'm not sure how it's played out in reality. Do most downstream users pin versions to avoid breakage?
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 require a major
update of the module? In rare cases we said yes, in most cases no. The
general feedback for the Puppet 3-4 migration was good. Only a few users
complaint that the latest release isn't compatible with their puppet3
env. They didn't check the CHANGELOG.md properly. For most of those
releases we did a minor one to announce that the upcoming major one
doesn't work with Puppet 3 anymore.

--eric0




Re: Get rid of Puppet4?

Eric Sorenson <eric@...>
 

Hi all, good to see this thread - I put some comments inline.

On Mar 21, 2018, at 2:45 AM, Tim Meusel <@bastelfreak> wrote:
On 03/21/2018 10:39 AM, Ewoud Kohl van Wijngaarden wrote:
On Wed, Mar 21, 2018 at 09:58:20AM +0100, Thomas Mueller wrote:
On 03/21/2018 09:50 AM, Tim Meusel wrote:
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 our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
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:
https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x
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.
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 them. We should
not encourage them to run outdated software. We should also point out
that people are not required to update their local module version, just
because we released a newer version.

I wrote that many times in issues and pull requests. I just realized
that our Puppet 4.7.1 is now EOL as well and we should maybe bump the
puppet version in all modules to at least 4.10.X? No matter if they use
data-in-modules or not.
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 'last of the line' before 5. It is a very short step from 4.10.x to 5 too, so i'd suggest being generous about dropping 4.x compatibility unless you *know* a module uses some 5.x-only construct.

This is in no way an official Puppet Inc statement but I suspect there will be a longer tail to 4.10 than just October 2018, given its inclusion in Satellite and widespread use out in the world.


But I don't think you can create a policy that fits for every
voxpupuli module. For some modules it maybe makes sense to support
older puppet and for others not.
Even if it's not a policy, some guidelines are good to have.
Does it work to make a new major version of the module that has tighter compatibility constraints? I think we talked about this as a community in the 3.x->4.x timeframe but I'm not sure how it's played out in reality. Do most downstream users pin versions to avoid breakage?

--eric0

Re: Get rid of Puppet4?

James Powis
 

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 major versions is perfectly acceptable in my book... I have now worked at 3 different shops using puppet to varying degrees of success, but every one of them have pinned version of the external modules they were using (after learning the hard way first). 

At a bare minimum, mirroring the PE LTS EOL dates would be recommended.

Thanks,

James R. Powis



On Wed, Mar 21, 2018 at 2:50 AM, Tim Meusel <tim@...> wrote:
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 our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.

I would like to get feedback from the community here. Do you think it is
still needed to support puppet 4 at all? Is 4.10 even to high as the
lowest version?

My point of view is that upgrades, since the AIO packages are available,
are really easy and everybody should be able to regularly update their
nodes. Dropping Puppet 4 would allow us to reduce the test matrix and
speed CI runs up. Also we would be safe with data-in-modules/hiera5. We
also need to keep in mind that not everybody is required to update their
used modules to the latest version, just because they are available.

The trigger for this was
https://github.com/camptocamp/puppet-systemd/pull/73. What are your
opinions on this topic?

Cheers, Tim





Re: Get rid of Puppet4?

David Hollinger
 

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 need to ensure that we don't make it too hard for users to utilize our tools.

While it does appear that 4.7.1 would be EOL based on the patch releases for PE 2016.4, the support lifecycle
lists the minor release as the supported version. I almost think we need some feedback from Hunner and Eputnam
before we make any decisions.

Regardless, I'm strongly against dropping support for any version that Puppet, Inc still provides support for.

Re: Get rid of Puppet4?

 

On 03/21/2018 10:39 AM, Ewoud Kohl van Wijngaarden wrote:
On Wed, Mar 21, 2018 at 09:58:20AM +0100, Thomas Mueller wrote:
On 03/21/2018 09:50 AM, Tim Meusel wrote:
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 our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
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:
https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x
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.
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 them. We should
not encourage them to run outdated software. We should also point out
that people are not required to update their local module version, just
because we released a newer version.

I wrote that many times in issues and pull requests. I just realized
that our Puppet 4.7.1 is now EOL as well and we should maybe bump the
puppet version in all modules to at least 4.10.X? No matter if they use
data-in-modules or not.

But I don't think you can create a policy that fits for every
voxpupuli module. For some modules it maybe makes sense to support
older puppet and for others not.
Even if it's not a policy, some guidelines are good to have.


Re: Get rid of Puppet4?

Ewoud Kohl van Wijngaarden
 

On Wed, Mar 21, 2018 at 09:58:20AM +0100, Thomas Mueller wrote:
On 03/21/2018 09:50 AM, Tim Meusel wrote:
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 our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
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: https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x
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.

But I don't think you can create a policy that fits for every voxpupuli module. For some modules it maybe makes sense to support older puppet and for others not.
Even if it's not a policy, some guidelines are good to have.

Re: Get rid of Puppet4?

Thomas Mueller <thomas@...>
 

On 03/21/2018 09:50 AM, Tim Meusel wrote:
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 our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
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: https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x

But I don't think you can create a policy that fits for every voxpupuli module. For some modules it maybe makes sense to support older puppet and for others not.

- Thomas

Get rid of Puppet4?

 

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 our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.

I would like to get feedback from the community here. Do you think it is
still needed to support puppet 4 at all? Is 4.10 even to high as the
lowest version?

My point of view is that upgrades, since the AIO packages are available,
are really easy and everybody should be able to regularly update their
nodes. Dropping Puppet 4 would allow us to reduce the test matrix and
speed CI runs up. Also we would be safe with data-in-modules/hiera5. We
also need to keep in mind that not everybody is required to update their
used modules to the latest version, just because they are available.

The trigger for this was
https://github.com/camptocamp/puppet-systemd/pull/73. What are your
opinions on this topic?

Cheers, Tim