Date   
Re: Releasing a Vault / Puppet integration in the VP namespace

 

Hi Lindsey,

Is it planned that Puppet Inc. keeps working on it and provides support
for raised issues, even after the migration to us? Should the module
only support the new lookup function, or anything else related to Vault?
Some of us contributed to https://github.com/jsok/puppet-vault in the past.

Cheers, Tim

On 9/24/18 11:25 PM, Lindsey Smith wrote:
Hi all,

One of the new capabilities in Puppet 6 is allowing agents to fetch data
for themselves at catalog application time. A key use case for this is
securely retrieving sensitive information like passwords from a secrets
store. Hashicorp Vault is one of the most popular of these and we've
started building an integration here:
https://github.com/tvpartytonight/vault_lookup

Because we want to make community contribution easier we'd like this to
live under the Vox Pupuli namespace on GitHub and the Forge. The module is
still a work in progress but when it in a usable state we'd like to have it
start life on the Forge in the puppet namespace.

Any concerns with this?

Lindsey



[ANN] Resource API v1.6.0 Release

David Schmitt
 

Hi /[fv]o(l)x/,

We're pleased to announce that version 1.6.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. 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 packages to deploy it in your infrastructure.

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

  • Allow SimpleProvider to handle composite namevars.
  • Implement allowances for device-specific providers.

The new release also contains the following notable changes:

  • Updates to the README
  • Add testing for supported puppet version branches

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 the Palo Alto firewall 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

--

Releasing a Vault / Puppet integration in the VP namespace

Lindsey Smith
 

Hi all,

One of the new capabilities in Puppet 6 is allowing agents to fetch data for themselves at catalog application time. A key use case for this is securely retrieving sensitive information like passwords from a secrets store. Hashicorp Vault is one of the most popular of these and we've started building an integration here: https://github.com/tvpartytonight/vault_lookup

Because we want to make community contribution easier we'd like this to live under the Vox Pupuli namespace on GitHub and the Forge. The module is still a work in progress but when it in a usable state we'd like to have it start life on the Forge in the puppet namespace.

Any concerns with this?

Lindsey

rake module:push, puppet-blacksmith, and puppet 6

David Schmitt
 

Hi folks,

until tomorrow's PDK and puppetlabs_spec_helper release automated module release jobs will need to have their puppet pinned to `~> 5.0`, to keep using the deprecated `puppet module build` command, which was removed in yesterday's puppet 6.0.0 release.

You can follow along PDK-1100 for the actual change required.


Apologies for the additional hiccup along the way,
David

--

Updates to CA command line interaction in Puppet 6

Maggie Dreyer <maggie@...>
 

Hello!

As you may know, we are about to release Puppet 6. This release contains a major update to the command line tools that are used to interact with Puppet's CA and certificates. The update makes the commands much faster and more reliable, removes duplication, and makes the interface easier to understand. However, this means that some scripts and workflows will have to be updated.

What is getting removed:
* puppet cert
* puppet ca
* puppet certificate
* puppet certificate_request
*puppet certificate_revocation_list

What is new:
* puppetserver ca (for CA tasks like signing and revoking certs)
* puppet ssl (for agent-side tasks like submitting a CSR and fetching a cert, though these steps will still usually be taken care of by an agent run)

We have been making updates to beaker and various test suites to account for this change. If you use Beaker to do any CA or certificate interaction in your tests, you will need to make some updates to test against Puppet 6:
1) Update to Beaker 4 and beaker-puppet 1. The latest release of both of these projects contains updates for these CA changes. Details.
2) Update any tests or pre-suites that use one of the removed commands to use the equivalent new command instead. For details, invoke `puppet cert` in Puppet 6 for help output containing the mapping of old commands to new alternatives. We will have docs pages up soon with this info.

The most recent Puppet 6 builds on puppet nightlies have these updates if you would like to try them out ahead of the release.

Please feel free to reach out to us if you have any further questions or feedback.

Thanks!

Re: [ANN] Resource API v1.5.0 Release

Hugo Deprez
 

+


Envoyé depuis ProtonMail mobile



-------- Message d'origine --------
On 13 sept. 2018 à 08:08, David Schmitt < david.schmitt@... > a écrit :

Hi all,

We're pleased to announce that version 1.5.0 of the Resource API has just been released.

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 that can be installed on all puppet versions since 4.7, and will be part of puppet6. 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 enhancements:

  • Allow providers to specify a title when there are multiple namevars, to make title patterns more usable. PDK-1150 #115 (da-ar)
  • Sensitive values are now usable like any other puppet4 datatype. PDK-1092 #117 (DavidS)
  • The puppetlabs-resource_api module now "supports" puppet 6. With the integration of Resource API in puppet 6, the module technically is not needed anymore. For backwards compatibility, and to provide a uniform experience across all puppet versions, it is still available, and will work on puppet6 (doing nothing).

The new release also contains the following notable bugfixes:

  • providers that implement simple_get_filter, are now handled correctly. MODULES-7679 #113 (da-ar)
  • default values are not shared across all resource instances anymore. #118 (DavidS)

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, David Schmitt for the Resource API maintainers.

--

[ANN] Resource API v1.5.0 Release

David Schmitt
 

Hi all,

We're pleased to announce that version 1.5.0 of the Resource API has just been released.

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 that can be installed on all puppet versions since 4.7, and will be part of puppet6. 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 enhancements:

  • Allow providers to specify a title when there are multiple namevars, to make title patterns more usable. PDK-1150 #115 (da-ar)
  • Sensitive values are now usable like any other puppet4 datatype. PDK-1092 #117 (DavidS)
  • The puppetlabs-resource_api module now "supports" puppet 6. With the integration of Resource API in puppet 6, the module technically is not needed anymore. For backwards compatibility, and to provide a uniform experience across all puppet versions, it is still available, and will work on puppet6 (doing nothing).

The new release also contains the following notable bugfixes:

  • providers that implement simple_get_filter, are now handled correctly. MODULES-7679 #113 (da-ar)
  • default values are not shared across all resource instances anymore. #118 (DavidS)

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, David Schmitt for the Resource API maintainers.

--

transition puppet/yum to ghoneycutt/yum

Garrett Honeycutt
 

Hello,

The ghoneycutt/yum has a new 2.0.0 release that supports all documented
options for yum.conf and individual .repo files. Be great to get
feedback from everyone and would like to transition the community and
the Forge's Approved status to this module.

Is anyone invested in the current module and would like to work with me
to move over any functionality?

https://github.com/ghoneycutt/puppet-module-yum

Best regards,
-g

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

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

Tp Honey
 

Hi, 

The final phase of our migration to Beaker 4 for modules is complete. puppet-module-gems has been released and the Puppet supported modules have been updated.

We are aware of the difficulties around these changes and thank you for your continued patience. Internally we are still looking at these issues, including documentation, process changes and potential different approaches to using beaker. 

Please feel free to reach out with any questions  / comments.

Thanks.

On Wed, 22 Aug 2018 at 18:01, Tp Honey <tp@...> wrote:
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: SNMP module

Hugo Deprez
 

Hello,

we are 2 years later, PR and issues are still numerous.
Still no plan for this module ?

Re: Puppet Apache Module

Martin Alfke
 

Hi Davin,

according to RedHat RHEL 6 has End of maintenance support 2 (Product retirement) until November 30, 2020 and End of extended lifecycle support at June 30, 20124.
(https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates)

Will you support the latest apache module with RHEL 6 support until end of RedHat support?

Best,
Martin

On 23. Aug 2018, at 17:29, Davin Hanlon <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: Puppet Apache Module

Ewoud Kohl van Wijngaarden <ewoud@...>
 

I also got the original notification via the VP ML. Anyway, better notified twice than not :) I really appreciate the heads up about these bigger changes. Luckily I'm unaffected.

On Wed, Aug 29, 2018 at 09:47:59AM -0700, Davin Hanlon wrote:
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
<https://forge.puppet.com/puppetlabs/apache>.

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
 

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

--