Date   
Puppet Apache Module

Davin Hanlon
 

Hello everyone!

Read on if you use the Puppet Apache module.

Quick note to let you know of some major work that we're performing to the module. As you probably know, Apache 2.2 has been end-of-lifed since the start of 2018 (https://httpd.apache.org/#apache-httpd-22-end-of-life-2018-01-01). Therefore, we're taking steps to remove support for that version of Apache from the module. This also impacts the operating systems that we will support for the module. The following operating systems won't be supported by the Apache module after the changes:
  • RHEL 5
  • RHEL 6
  • CentOS 5
  • CentOS 6
  • Oracle Linux 6
  • Scientific Linux 6
  • SLES 11
Any users that use either Apache 2.2 or use one of the above operating systems should pin to an older version of the module. We will continue to support these operating systems for older versions of the module.

Feel free to reach out if you've any questions or comments.

Thanks,
The Puppet Modules Team
--
Davin Hanlon
Product Owner, Modules
Puppet. The shortest path to better software.

Puppet Apache Module

Davin Hanlon
 

See below - missed the Vox Pupuli mailing list off the original notification. Let me know your feedback.

Thanks,
Davin


On Thursday, August 23, 2018 at 4:29:49 PM UTC+1, Davin Hanlon wrote:
Hello everyone!

Read on if you use the Puppet Apache module.

Quick note to let you know of some major work that we're performing to the module. As you probably know, Apache 2.2 has been end-of-lifed since the start of 2018 (https://httpd.apache.org/#apache-httpd-22-end-of-life-2018-01-01). Therefore, we're taking steps to remove support for that version of Apache from the module. This also impacts the operating systems that we will support for the module. The following operating systems won't be supported by the Apache module after the changes:
  • RHEL 5
  • RHEL 6
  • CentOS 5
  • CentOS 6
  • Oracle Linux 6
  • Scientific Linux 6
  • SLES 11
Any users that use either Apache 2.2 or use one of the above operating systems should pin to an older version of the module. We will continue to support these operating systems for older versions of the module.

Feel free to reach out if you've any questions or comments.

Thanks,
The Puppet Modules Team
--
Davin Hanlon
Product Owner, Modules
Puppet. The shortest path to better software.

Re: Beaker 3 to Beaker 4 migration for puppet modules.

Tp Honey
 

Hi,

Yesterday 0.3.9 of puppet-module-gems was released. This adds Beaker 3 as a dependency for system tests. The added dependencies have upper bounds to prevent future major releases of those gems from affecting modules. The Puppet supported modules have been updated to take advantage of this change. eg puppetlabs-stdlib 

Changes are being tested for moving to Beaker 4. There will be another release of puppet-module-gems, along with PR's to the supported puppet modules. 

Please feel free to reach out if you have any questions / comments.

Thanks


On Wed, 15 Aug 2018 at 17:45, Tp Honey <tp@...> wrote:
Hi,
    as you may be aware there was a release of Beaker 4 gem in the last week, here are some proof of concept PR's for puppet modules that show the necessary code changes and the dependency changes required for this migration. 
The Beaker team have detailed the technicalities of these beaker changes here Upgrade_from_3_to_4
Longer term we are going to put these changes into puppet-module-gems pinning first to beaker 3 then moving to beaker 4 for supported puppet modules. 

Please feel free to reach out if you have further questions.

Thanks
TP Honey

Re: Beaker 3 to Beaker 4 migration for puppet modules.

Tp Honey
 

Thanks for the feedback, first and foremost. 
I will try to answer this as best I can. 
The release of beaker 4 was not publicised enough, and we are working internally on improving this. No harm was meant with the release, and we do not want this to happen again. There are beaker announcements here https://groups.google.com/forum/#!forum/puppet-beaker  It was announced that a major version release would be upcoming in the previous minor release, with one month lead time: https://groups.google.com/forum/#!topic/puppet-beaker/U_4vhwjav7o We then announced the major version release: https://groups.google.com/forum/#!topic/puppet-beaker/zuTHYq0FluA. However it is clear that this was not enough. 

For the modules team at puppet, it highlights an issue that we need to be careful on how we pin dependencies and have proper upper bounds set. We have work in flight that will make changes to puppet-module-gems to include beaker, with strict version bounding. 

The use of beaker has grown in scope usage in (multiple projects) and in terms of depth (features) Agreed that we need to improve documentation around its use and development.
Writing acceptance tests is hard, unfortunately the best way to figure it all out, is by mimicry. Looking at existing modules is a non-ideal way to learn the tricks of provisioning / setup / tests / tear down. But it is extensive. The puppet supported modules, extensively use beaker / beaker-rspec. We now use travis-ci with docker images of popular distributions to ensure that pr's are good to merge. It does work well. What would help most, documentation around the individual components. Or a guide on how to setup a module for acceptance tests. Or how to write a good acceptance test.

Apologies again, and thank you for your patience. 
TP Honey

On Wed, 15 Aug 2018 at 18:22, Ewoud Kohl van Wijngaarden <ewoud@...> wrote:
On Wed, Aug 15, 2018 at 05:45:03PM +0100, Tp Honey wrote:
>    as you may be aware there was a release of Beaker 4 gem in the last
>week

I appreciate the thread, but was there a place I could have gotten a
heads up of such a major bump before the actual release?

> here are some proof of concept PR's for puppet modules that show the
>necessary code changes and the dependency changes required for this
>migration.
>puppetlabs-stdlib PR
><https://github.com/puppetlabs/puppetlabs-stdlib/pull/937>  and puppetlabs-apt
>PR <https://github.com/puppetlabs/puppetlabs-apt/pull/779>
>The Beaker team have detailed the technicalities of these beaker changes
>here Upgrade_from_3_to_4
><https://github.com/puppetlabs/beaker/blob/4.0.0/docs/how_to/upgrade_from_3_to_4.md>

The links to beaker-* are incorrect,
https://github.com/puppetlabs/beaker/pull/1541 should fix them.

>Longer term we are going to put these changes into puppet-module-gems
><https://github.com/puppetlabs/puppet-module-gems> pinning first to beaker
>3 then moving to beaker 4 for supported puppet modules.
>
>Please feel free to reach out if you have further questions.

In my experience it's very hard to find documentation on beaker. For
example, it took a long time before I figured out that serverspec[1] is
used and well documented.

A high level overview of how it works and how I use it as a developer
writing specs would be greatly appreciated.

[1]: https://serverspec.org/



Re: Beaker 3 to Beaker 4 migration for puppet modules.

Ewoud Kohl van Wijngaarden <ewoud@...>
 

On Wed, Aug 15, 2018 at 05:45:03PM +0100, Tp Honey wrote:
as you may be aware there was a release of Beaker 4 gem in the last
week
I appreciate the thread, but was there a place I could have gotten a heads up of such a major bump before the actual release?

here are some proof of concept PR's for puppet modules that show the
necessary code changes and the dependency changes required for this
migration.
puppetlabs-stdlib PR
<https://github.com/puppetlabs/puppetlabs-stdlib/pull/937> and puppetlabs-apt
PR <https://github.com/puppetlabs/puppetlabs-apt/pull/779>
The Beaker team have detailed the technicalities of these beaker changes
here Upgrade_from_3_to_4
<https://github.com/puppetlabs/beaker/blob/4.0.0/docs/how_to/upgrade_from_3_to_4.md>
The links to beaker-* are incorrect, https://github.com/puppetlabs/beaker/pull/1541 should fix them.

Longer term we are going to put these changes into puppet-module-gems
<https://github.com/puppetlabs/puppet-module-gems> pinning first to beaker
3 then moving to beaker 4 for supported puppet modules.

Please feel free to reach out if you have further questions.
In my experience it's very hard to find documentation on beaker. For example, it took a long time before I figured out that serverspec[1] is used and well documented.

A high level overview of how it works and how I use it as a developer writing specs would be greatly appreciated.

[1]: https://serverspec.org/

Beaker 3 to Beaker 4 migration for puppet modules.

Tp Honey
 

Hi,
    as you may be aware there was a release of Beaker 4 gem in the last week, here are some proof of concept PR's for puppet modules that show the necessary code changes and the dependency changes required for this migration. 
The Beaker team have detailed the technicalities of these beaker changes here Upgrade_from_3_to_4
Longer term we are going to put these changes into puppet-module-gems pinning first to beaker 3 then moving to beaker 4 for supported puppet modules. 

Please feel free to reach out if you have further questions.

Thanks
TP Honey

[ANN] Resource API v1.4.2 Release

David Schmitt
 

Hi vox,

We're pleased to announce that version 1.4.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. Using a little bit of ruby, you can finally get rid of that brittle exec, or manage that one API that eluded you until now.

It is provided as a Ruby gem to be referenced within modules. Support for it has been included as an experimental feature in the Puppet Development Kit (see pdk new provider --help). Use the resource_api module or the puppet 6 nightly packages to deploy it in your infrastructure.

The new release of the Resource API following notable bugfix:

  • Allow an attribute with default boolean value to be set correctly #110 (da-ar)

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. The README gets you going quickly. To see some example code see this simple Philips Hue type or this experimental apt_key provider.

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


Thanks, the other David

--

[ANN] Resource API v1.4.1 Release

David Schmitt
 

Hi all,

We're pleased to announce that version 1.4.1 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. Using a little bit of ruby, you can finally get rid of that brittle exec, or manage that one API that eluded you until now.

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

  • Fix "undefined method `rs_value'" error with metaparams like require and subscribe
  • Improve log_exception output from PuppetContext
  • Minor code changes to allow providers be loaded without puppet

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. The README gets you going quickly. To see some example code see this simple Philips Hue type or this experimental apt_key provider.

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

Thanks, the Davids

--

Re: Puppet module autofs assistance

David Hollinger
 

Justin,

the issue about the `format` parameter for Concat is an issue where your Puppet environment isn't properly syncing plugins from modules (I.E. Ruby facts, functions, types, providers). The 'format' parameter was introduced in the puppetlabs-concat module some time ago and the easiest workaround is to run '/opt/puppetlabs/bin/puppet generate types --environment <environment_name>'. That's what worked for me.

That said, the core of the issue is a bug in Puppet itself rather than any issue with puppetlabs-concat or puppet-autofs. What version of puppet are you on?

Announcement: Puppet Development Kit RFC process and pdk-planning repo

Jesse Scott
 

The Puppet Development Kit team is excited to introduce a new RFC-based open-source planning and design process for the PDK project!

While many changes to the PDK, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow, some changes are more substantial.

Today, we are committing to putting these more substantial features through an “in the open” design process prior to implementation work starting. This new design process is similar to the internal process that we had been using, with the primary difference being that the whole PDK community will be able to participate in the new process.

We welcome and encourage feedback from all members of the PDK community, whether you just started using Puppet and PDK last week or have been working with Puppet for years. A diversity of perspectives and experience levels will help make PDK better for everyone.

You can learn more about our new RFC process as well as review recently introduced proposals from the PDK team in the new “pdk-planning” Github repository located at https://github.com/puppetlabs/pdk-planning.


Thanks!

-- The PDK Team

Re: Puppet module autofs assistance

Bollinger, John C
 

Hello Justin,

 

I’m sorry you’re having difficulty.

 

The first problem appears to be with your formatting of the value of the 'mappings' key in the value of the 'mapfiles' parameter.  What is expected is an array of hashes that each one contains both a 'key' and an 'fs', and optionally 'options'.  Instead, you have presented an array of three separate hashes, each with just one key.  You’re close; it looks like what you actually want is this:

 

home:

  ensure: 'present'

  path: '/etc/auto.home'

  mappings:

    - key: '*'

      options: 'rw'

      fs: 'nfs-1:/home/&'

     

That array of hashes syntax always looks a bit weird to me, though.  If you think the same, then you could consider formatting it this way instead, which I think is equivalent:

 

home:

  ensure: 'present'

  path: '/etc/auto.home'

  mappings:

    - { key: '*', options: 'rw', fs: 'nfs-1:/home/&' }

 

===

 

I’m afraid I cannot explain the error about a 'format' parameter to Concat_file[/etc/auto.master], however.  Puppet-autofs does not directly declare any concat_file resources, or provide resource defaults for them, or override any of them (nor should it). Version 5.0.0 does not declare a ‘format’ parameter for _any_ class or resource, and none of its own classes or resources accept such a parameter.

 

If I were to speculate, I’d guess that the error arises from in-scope resource defaults or from a resource override, somewhere among your own local manifests.

 

 

Best regards,

 

John Bollinger

 

 

From: voxpupuli@groups.io [mailto:voxpupuli@groups.io] On Behalf Of J so
Sent: Wednesday, July 11, 2018 3:25 AM
To: voxpupuli@groups.io
Subject: [voxpupuli] Puppet module autofs assistance

 

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

 




Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer

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

--