Date   

PDK 2.0.0 now available

Jesse Scott
 

Hello!

The PDK development team is pleased to announce the latest release of the Puppet Development Kit (PDK), version 2.0.0!

Highlights from the 2.0.0 release include:

- Support for Puppet 7.x and Ruby 2.7
- The PDK gem now requires at least Ruby 2.4.0. PDK OS-native packages no longer include Puppet 4.x or the Ruby 2.1.9 runtime environment.
- Added `pdk new fact` and `pdk new function` commands
- Lots of updates to improve the functionality and customizability of templated CI configurations

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

To install or upgrade to this new version, use your platform's package manager (see https://puppet.com/docs/pdk/2.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: Modulesync Config 4.0.0

David Schmitt
 

Given that puppet5 is EOL RSN I wouldn't hold my breath for any new platforms being supported in that stream. Similarly with puppet7 being released, I expect little investment in adding new platforms to puppet6 going forward.

Cheers, David


On Sun, 29 Nov 2020 at 21:11, Tim Meusel <tim@...> wrote:
Hi people,

thanks for all the awesome work Ewoud!

Tiny update here: you might see failing tests on Ubuntu 20.04 with
Puppet 5. That's because Puppet does not provide packages for this
distro. The same applies for Fedora 33 on Puppet 5/6 and Fedora 32 on
Puppet 5, but we rarely have those in our metadata.json.

We already merged a few PRs where *only* acceptance tests fail for the
above mentioned platforms. IMO it's fine to continue with this until
Puppet provides packages / we figure out how do exclude those OS/Puppet
combinations from our test matrix.

cheers, Tim

On 26.11.20 13:37, Ewoud Kohl van Wijngaarden wrote:
> Hello everyone,
>
> You may have seen a wave of activity yesterday. Bastelfreak and I
> released our msync config 4.0.0.
>
> The major change was from Travis CI to Github Actions. In doing so, the
> test matrix has become dynamic. This means that metadata.json drives it.
> If you list Puppet >= 5.5.8 < 7.0.0 it will run the unit tests on Puppet
> 5 & 6. To add Puppet 7 support, just update metadata.json and it'll run
> the tests. Similar, Puppet 5 can be dropped in the same way. We found
> some modules which didn't declare any support or still only Puppet 4.
> Most of these have been cleaned up.
>
> Similarly, if there are acceptance tests it will run them. That means
> that if you list CentOS 6 in metadata.json and there are accepance
> tests, it will run them. We found a few broken modules and they have
> dropped CentOS 6. There are also a bunch of modules where the acceptance
> tests all fail because previously they didn't run. There are still a
> bunch of them open now.
>
> Now there are 52 open modulesync PRs.
>
> https://github.com/pulls?q=is%3Aopen+is%3Apr+archived%3Afalse+user%3Avoxpupuli+label%3Amodulesync
>
>
> For each one I left a message why they failed but I don't have time to
> fix all issues. This is where you come in.
>
> For a few Github Actions didn't trigger for some reason. I'll see if I
> can work on that.
>
> Then there are modules where there are problems that need code changes.
> Either in the modules or in the tests. These have the tests-fail label.
>
> I'd like to ask everyone to look at the modules they care about and fix
> them. I'll be happy to advise but often I don't even know the software.
>
> If modules are really broken for a longer time and nobody steps up I'd
> suggest to mothball them. This means removing it from the modulesync
> config so they're not holding us back. They should also have an open
> issue which describes the state of the module.
>
> Regards,
> Ewoud Kohl van Wijngaarden
>
>
>
>
>







Re: Modulesync Config 4.0.0

 

Hi people,

thanks for all the awesome work Ewoud!

Tiny update here: you might see failing tests on Ubuntu 20.04 with
Puppet 5. That's because Puppet does not provide packages for this
distro. The same applies for Fedora 33 on Puppet 5/6 and Fedora 32 on
Puppet 5, but we rarely have those in our metadata.json.

We already merged a few PRs where *only* acceptance tests fail for the
above mentioned platforms. IMO it's fine to continue with this until
Puppet provides packages / we figure out how do exclude those OS/Puppet
combinations from our test matrix.

cheers, Tim

On 26.11.20 13:37, Ewoud Kohl van Wijngaarden wrote:
Hello everyone,

You may have seen a wave of activity yesterday. Bastelfreak and I
released our msync config 4.0.0.

The major change was from Travis CI to Github Actions. In doing so, the
test matrix has become dynamic. This means that metadata.json drives it.
If you list Puppet >= 5.5.8 < 7.0.0 it will run the unit tests on Puppet
5 & 6. To add Puppet 7 support, just update metadata.json and it'll run
the tests. Similar, Puppet 5 can be dropped in the same way. We found
some modules which didn't declare any support or still only Puppet 4.
Most of these have been cleaned up.

Similarly, if there are acceptance tests it will run them. That means
that if you list CentOS 6 in metadata.json and there are accepance
tests, it will run them. We found a few broken modules and they have
dropped CentOS 6. There are also a bunch of modules where the acceptance
tests all fail because previously they didn't run. There are still a
bunch of them open now.

Now there are 52 open modulesync PRs.

https://github.com/pulls?q=is%3Aopen+is%3Apr+archived%3Afalse+user%3Avoxpupuli+label%3Amodulesync


For each one I left a message why they failed but I don't have time to
fix all issues. This is where you come in.

For a few Github Actions didn't trigger for some reason. I'll see if I
can work on that.

Then there are modules where there are problems that need code changes.
Either in the modules or in the tests. These have the tests-fail label.

I'd like to ask everyone to look at the modules they care about and fix
them. I'll be happy to advise but often I don't even know the software.

If modules are really broken for a longer time and nobody steps up I'd
suggest to mothball them. This means removing it from the modulesync
config so they're not holding us back. They should also have an open
issue which describes the state of the module.

Regards,
Ewoud Kohl van Wijngaarden





Modulesync Config 4.0.0

Ewoud Kohl van Wijngaarden
 

Hello everyone,

You may have seen a wave of activity yesterday. Bastelfreak and I released our msync config 4.0.0.

The major change was from Travis CI to Github Actions. In doing so, the test matrix has become dynamic. This means that metadata.json drives it. If you list Puppet >= 5.5.8 < 7.0.0 it will run the unit tests on Puppet 5 & 6. To add Puppet 7 support, just update metadata.json and it'll run the tests. Similar, Puppet 5 can be dropped in the same way. We found some modules which didn't declare any support or still only Puppet 4. Most of these have been cleaned up.

Similarly, if there are acceptance tests it will run them. That means that if you list CentOS 6 in metadata.json and there are accepance tests, it will run them. We found a few broken modules and they have dropped CentOS 6. There are also a bunch of modules where the acceptance tests all fail because previously they didn't run. There are still a bunch of them open now.

Now there are 52 open modulesync PRs.

https://github.com/pulls?q=is%3Aopen+is%3Apr+archived%3Afalse+user%3Avoxpupuli+label%3Amodulesync

For each one I left a message why they failed but I don't have time to fix all issues. This is where you come in.

For a few Github Actions didn't trigger for some reason. I'll see if I can work on that.

Then there are modules where there are problems that need code changes. Either in the modules or in the tests. These have the tests-fail label.

I'd like to ask everyone to look at the modules they care about and fix them. I'll be happy to advise but often I don't even know the software.

If modules are really broken for a longer time and nobody steps up I'd suggest to mothball them. This means removing it from the modulesync config so they're not holding us back. They should also have an open issue which describes the state of the module.

Regards,
Ewoud Kohl van Wijngaarden


Re: Conversion from Travis CI to Github Actions

Alex Fisher
 

First up, wow! Great work on the migration to github actions!
I'm really looking forward to ditching travis. :)

As for REFERENCE.md

I get the sentiment, (generated things don't belong in repos), but I don't like the sound of option 1 or 3 personally.

90% of the time I read a REFERENCE.md it's via github, not via the forge.
We've also had several doc PRs recently where being able to review the changes to the REFERENCE.md was important.
I actually wish I could do that more often.

Are there any other options that might be viable?  eg. Could we store the REFERENCE.md in its own branch that is auto updated on each merge to master???


Conversion from Travis CI to Github Actions

Ewoud Kohl van Wijngaarden
 

Hello everyone,

I've started an effort to migrate our Puppet modules from Travis CI to Github Actions. The PR is open:

https://github.com/voxpupuli/modulesync_config/pull/683

I think I've mostly covered the CI part (relative straight forward conversion).

For releases I do have an open question. I would like to stop storing REFERENCE.md in git since it's a generated document. That means we need to at least generate it during releases. That's easy (call the right rake task), but a lot of modules aren't really documented in a way that puppet-strings does anything useful.

So option 1 is to always generate REFERENCE.md, no matter if it's garbage.

Option 2 is to keep REFERENCE.md in the repo but always regen it if it exists so it's up to date on release.

Option 3 is to add a modulesync option. 3a would be to make it opt-in and 3b to make it opt-out.

Maybe I missed another option.

I'd love to get some feedback on this. Not only about the release part, but the whole migration. Feedback on the PR would be a good place.


Facter 4.0.44

Bogdan Irimie
 

Facter 4.0.44

Base 64 encoded!Added

  • Added disk_type field to disk fact #2145

Base 64 encoded! Fixed

  • (FACT-2806) Fix os.release.minor on amazon 6 #2133
  • (FACT-2832) Use full path for augparse command #2135
  • (FACT-2815) Added timing for cached facts #2134
  • (FACT-2834) Dynamically get AIX proc number #2147
  • (FACT-2829) Fixed partitions and mount points facts #2146
  • (maint) Use strings instead of symbols for os names #2149

Feel free to reach out on slack or open a ticket on https://tickets.puppetlabs.com/projects/FACT.

Or, even better, open a PR on the facter repository.


Puppet 7 win32 gem removals

Josh Cooper
 

Hi all,

I wanted to make sure you saw my announcement that Puppet 7 will no longer vendor win32-* gems, as it may affect some vox owned modules. It looks like puppet-windows_env will be ok because it only relies on win32 code in puppet (puppet/util/windows/security) and ruby itself (win32/registry), but I wanted to double check. Let me know if you have any questions about that or the Puppet 7 release in general.

Thanks!
Josh

--
Josh Cooper | Software Engineer


Facter 4.0.42

Andrei
 

                

Facter 4.0.42

Added

  • (FACT-2792) Show not supported message for facter -p #2119

Fixed

  • (FACT-2805) Read available memory from MemAvailable #2109
  • (maint) Avoid deadlock of Facter::Core::Execution.execute #2114
  • (maint) Fix external fact cache #2123

Feel free to reach out on slack or open a ticket on https://tickets.puppetlabs.com/projects/FACT.

Or, even better, open a PR on the facter repository.

Collapse


Facter 4.0.40

Florin Dragos <florin@...>
 

Facter 4.0.40


Added

  • (FACT-2774) Extend facter API with resolve. [#2054]

Fixed

  • (FACT-2798) Set color to true, fix Facter.log_exception #2105
  • (FACT-2816) - Fix ec2 fact issues when on non ec2 systems #2106
  • (FACT-2799) Fix fact loading for nested fact calls #2108
  • (FACT-2786) Fix fact caching if fact is defined in multiple groups #2089
  • Fix for blockdevice_*_size legacy fact on Aix and Solaris #2111

Feel free to reach out on slack or open a ticket on https://tickets.puppetlabs.com/projects/FACT.

Or, even better, open a PR on the facter repository.


Facter 4.0.43

Sebastian Miclea
 

Facter 4.0.43


Fixed

  • (FACT-2810) Fix dmi.board_asset_tag and dhcp #2125
  • (FACT-2817) Only invalidate session cache on clear and reset. #2121
  • (maint) Fix virtual_detector #2128
  • (FACT-2806) Fix physicalprocessorcount #2127
  • (FACT-2809) Fixed output differences on solaris #2116 

Feel free to reach out on slack or open a ticket on https://tickets.puppetlabs.com/projects/FACT.

Or, even better, open a PR on the facter repository.


Facter 4.0.38 is now available

Bogdan Irimie
 

Facter 4.0.38

Added

  • (FACT-2319) Added debugonce method #2085
  • (FACT-2327) added list method #2088
  • (FACT-2320) Added warnonce method #2084
  • (FACT-2315) Added warn method to facter api #2083

Fixed

  • (FACT-2784) Fixed rhel os release fact #2086

Feel free to reach out on slack or open a ticket on https://tickets.puppetlabs.com/projects/FACT.

Or, even better, open a PR on the facter repository.


Faster 4.0.37

Sebastian Miclea
 

Hi everyone,

We are happy to announce that Facter 4.0.37 is released.

 

Here’s what’s new:

Added

Fixed

 

 

Feel free to reach out on slack or open a ticket on https://tickets.puppetlabs.com/projects/FACT. Or, even better, open a PR on the facter-ng  repository.

 

Best regards,

Sebastian Miclea

 

 


Facter 4.0.34

Florin Dragos <florin@...>
 

Hello everyone,

We are happy to announce that Facter 4.0.34 has been released.

Here's what's new:

Added

  • (FACT-2739) Extend os hierarchy to consider multiple os families #2016
  • Add FreeBSD memory facts #2020
  • Add FreeBSD dmi facts #2021
  • (FACT-2727) add load averages for Solaris #2023

Fixed

  • (FACT-2714) Fix dhcp on solaris 10 #2013
  • (FACT-2732) OracleLinux 7 and Scientific Linux 7 OS facts incorrect in Facter 4.0.30 #2014
For any issues, feel free to reach out on slack or open a ticket on https://tickets.puppetlabs.com/projects/FACT. Or, even better, open a PR on the facter repository, targeting the 4.x branch.

Best regards,
Florin Dragos


FW: Facter 4.0.33

Sebastian Miclea
 

Hi everyone,

We are happy to announce that Facter 4.0.33 is released.

 

Here’s what’s new:

Added

  1. (FACT-2040) Added solaris memory resolver #1999 (sebastian-miclea)

Fixed

  1. (FACT-2735) virtual not working on EXADATA baremetal #2004 (IrimieBogdan)
  2. (FACT-2736) networking facts don't work on EXADATA baremetal #2008 (IrimieBogdan)
  3. (FACT-2724) Confine blocks behave differently with Facter 4, causing spec tests to suddenly fail #2010 (IrimieBogdan)

 

 

Feel free to reach out on slack or open a ticket on https://tickets.puppetlabs.com/projects/FACT with facter-ng label. Or, even better, open a PR on the facter-ng  repository.

 

Best regards,

Sebastian Miclea

 

 


[vox-pupuli-tasks] Development update

 

Hi people!

Robert and I worked the past weeks on our Rails application to manage
git repositories and Puppet modules - Vox-Pupuli-Tasks. For those of you
that don't know yet what it is, please check out:
https://github.com/voxpupuli/vox-pupuli-tasks#vox-pupuli-tasks---the-webapp-for-community-management

The application is now in a state where it reliable detects merge
conflicts and CI errors and attaches a `merge-conflicts` and a
`tests-fail` label in those cases. If the errors are resolved, the
labels are automatically removed. This allows all of us, if we want to
review code, to focus on those pull requests. I created a github search
query for them:

https://github.com/pulls?utf8=%E2%9C%93&;q=is%3Aopen+is%3Apr+user%3Avoxpupuli+archived%3Afalse+status%3Asuccess+sort%3Aupdated-desc+-label%3Amerge-conflicts

While we process all the pull requests, we also gather more information,
which we display in the UI: https://voxpupu.li/

The next thing we want to work on is multi github-org support. We want
to enable other communities to use this for their own github namespace.
This would also allow Puppet Inc to use it. The related github issue is
https://github.com/voxpupuli/vox-pupuli-tasks/issues/115.

As always: If you would prefer another feature, have opinions on #115
our any other feedback, don't hesitate to reply here or on any of the
open issues.

Cheers,
Robert and Tim


Facter 4.0.31 is now available

Bogdan Irimie
 

Hi,

The Facter team is happy to announce the release of Facter 4.0.31
cherries_fans.gif

Added

  • (FACT-2718) Block custom facts #1996 
  • (FACT-2230) Add Aix memory facts #1994
  • (FACT-2220) Add Aix disks fact #1987
  • (FACT-2708) Add man pages #1984

Fixed

  • (FACT-2710) Correctly display vmware info #1988
  • (FACT-2702) Fix system_profiler legacy facts #1982
  • Handle Time and Symbol in executable facts #1977
Feel free to reach out on slack or open a ticket on https://tickets.puppetlabs.com/projects/FACT with facter-ng label. Or, even better, open a PR on the facter repository, targeting the 4.x branch.

Best regards,
Bogdan Irimie


Puppet Webhook 2.1.2 now available

David Hollinger
 

Hello Vox!

We are happy to announce that Puppet Webhook version 2.1.2 has been released.

This is mainly a bug fix update:

- Make sure that the `api/v1/r10k/module` endpoint passes both the request data and headers to the parser.
- Ensure the systemd service provided by the packages sets `RACK_ENV` to production.

In addition, the platform-specific packages now also support Ubuntu 20.04.

Full release notes are at: https://github.com/voxpupuli/puppet_webhook/releases/tag/v2.1.2

You can install or update to this new version using your OS's package manager or by downloading the appropriate RPM or DEB package from the releases page.

Additionally, the Docker container has been updated to version 2.1.2 as well.


Re: RabbitMq puppet module query

David Hollinger
 

Purushottam,

The latest version of the RabbitMQ module (10.1.1) should be capable of installing and managing RabbitMQ 3.6.6

You'll just have to make sure you set the `$package_ensure` parameter in the init.pp to the version you want to install.

Regards,
David


RabbitMq puppet module query

Purushottam tiwary <purushottam.tiwary@...>
 

Hi Vox,

Hope you are doing well.!!
I was using rabbitmq puppet module 4.0.0 long back and the same module is being used for managing the rabbitmq provisioning on RHEL6 and Puppet Enterprise 3.3.1.

Now we have to migrate to RHEL7 and use Puppet 5.5.x. The above rabbitmq puppet module version 4.0.0 seems incompatible with Puppet 5 on RHEL7.

Could you please suggest which rabbitmq puppet module shall i pull for Puppet forge so that existing rabbitmq server should be as it is and also able to continue with the rabbitmq existing version (3.6.6).

Thank you in advance.

With best Regards,
Purushottam

1 - 20 of 372