Date   

Facter 4.0.30 is now available

Andrei Filipovici <andrei.filipovici@...>
 

Hello,

The Facter team is happy to announce the release of Facter 4.0.30

Here is what changed:

Added

  • (FACT-2690) Add Hyper-V fact for Linux #1968
  • (FACT-2694) Add linux openvz fact #1970
  • (FACT-2656) Add solaris networking facts #1947
  • (FACT-2689) Add hypervisors docker fact #1950
  • (FACT-2683) Add remaining legacy networking facts for OSX #1952
  • (FACT-2692) Add hypervisors lxc fact #1953
  • (FACT-2691) Add kvm fact on linux #1955
  • (FACT-2697) Add Xen fact #1957
  • (FACT-2695) Add virtualbox hypervisor fact #1956
  • (FACT-2693) Add systemd_nspawn fact #1958
  • (FACT-2696) Add vmware fact #1963

Bug fixes

  • (FACT-2673) Fix mountpoints logic for osx #1971
  • (maint) Silent solaris_zones facts on FreeBSD #1954

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,
Andrei Filipovici


Re: How to report broken documentation link? voxpupuli/puppet-php

Ewoud Kohl van Wijngaarden
 

On Tue, Jul 07, 2020 at 12:11:32PM +0100, John Gilmartin wrote:
The mayflower.de link to the documentation of the php::extension resource'
on the following page is broken. What is the proper way to report this and
request a working documentation link please? Thanks for guidance.
https://github.com/voxpupuli/puppet-php
On Github there's a link Issues. Even more appreciated would be a pull request. This is also in CONTRIBUTING.md[1]

https://github.com/voxpupuli/puppet-php/blob/master/.github/CONTRIBUTING.md


How to report broken documentation link? voxpupuli/puppet-php

John Gilmartin <johnggilmartin@...>
 

The mayflower.de link to the documentation of the php::extension resource' on the following page is broken. What is the proper way to report this and request a working documentation link please? Thanks for guidance.


Re: squid::acl does not support sourcing acl contents from files as SQUID does

Ewoud Kohl van Wijngaarden
 

On Thu, Jul 02, 2020 at 04:27:51PM +0000, sc.hechelmann@extaccount.com wrote:
Hi there,

we ran into an issue with puppet-squid internally and wanted to share the fix with you.

puppet-squid seems to only allow specifying acl elements directly and seems to be missing
support for the 2nd form SQUID allows, to pull in acl contents from an external file.

Quoting from squid documentation (relvant parts marked):
# TAG: acl
# Defining an Access List
#
# Every access list definition must begin with an aclname and acltype,
# followed by either type-specific arguments or a quoted filename that
# they are read from.
#
# acl aclname acltype argument ...
# acl aclname acltype "file" ...
#
# When using "file", the file should contain one item per line.

The following patch enables the template used to support the present SQUID feature.

templates/squid.conf.acl.erb - acls with files need filename in double quotes (")

- If "e" starts with "/" emit double quotes around "e"

diff templates/squid.conf.acl.erb.orig templates/squid.conf.acl.erb
--- templates/squid.conf.acl.erb.orig
+++ templates/squid.conf.acl.erb
@@ -1,5 +1,5 @@
# <%= @comment %>
<% @entries.sort.each do |e| -%>
-acl <%= @aclname %> <%= @type %> <%= e %>
+acl <%= @aclname %> <%= @type %> <%- if e.to_s.start_with?("/") -%>"<%- end -%><%= e %><%- if e.to_s.start_with?("/") -%>"<%- end -%> <% end -%>
Ths sounds valid but please submit this as a patch to Github
https://github.com/voxpupuli/puppet-squid

That way you get proper credit but it's also much easier to review for others.


squid::acl does not support sourcing acl contents from files as SQUID does

sc.hechelmann@...
 

Hi there,

 

we ran into an issue with puppet-squid internally and wanted to share the fix with you.

 

puppet-squid seems to only allow specifying acl elements directly and seems to be missing
support for the 2nd form SQUID allows, to pull in acl contents from an external file.

 

Quoting from squid documentation (relvant parts marked):

#  TAG: acl

#       Defining an Access List

#

#       Every access list definition must begin with an aclname and acltype,

#       followed by either type-specific arguments or a quoted filename that

#       they are read from.

#

#          acl aclname acltype argument ...

#          acl aclname acltype "file" ...

#

#       When using "file", the file should contain one item per line.

 

The following patch enables the template used to support the present SQUID feature.

 

templates/squid.conf.acl.erb - acls with files need filename in double quotes (")

-          If “e” starts with “/” emit double quotes around “e”

 

diff templates/squid.conf.acl.erb.orig templates/squid.conf.acl.erb

--- templates/squid.conf.acl.erb.orig

+++ templates/squid.conf.acl.erb

@@ -1,5 +1,5 @@

# <%= @comment %>

<% @entries.sort.each do |e| -%>

-acl <%= @aclname %> <%= @type %> <%= e %>

+acl <%= @aclname %> <%= @type %> <%- if e.to_s.start_with?("/") -%>"<%- end -%><%= e %><%- if e.to_s.start_with?("/") -%>"<%- end -%> <% end -%>

 

Kind regards | Mit freundlichen Grüßen,

 

Christian Hechelmann

ATOS IT Solutions

for: IT/DT, IT-Sicherheit MCG/D

Mercedes Car Group/Development

 

Daimler AG, ITP/DT
IT-Sicherheit und Datenschutz RD / IT Security and Data Privacy RD
HPC 059/G083 - Hans-Klemm-Str.
5 - 71034 Böblingen

Phone +49-(0)70 31 90-8 41 80

Fax     +49-(0)70 31 90-8 41 11

 


If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.


Facter 4.0.29 is now available

Oana Tanasoiu <oana.tanasoiu@...>
 

Hello,

The Facter team is happy to announce the release of Facter 4.0.29


Here is what changed:

Added

  • (FACT-2218) virtual fact for OSX #1945
  • (FACT-2232) Add Aix networking facts #1937

Bug fixes

  • (FACT-2676) fix os identifier for opensuse-leap #1944
  • FACT-2679 Get DHCP for all interfaces on OSX #1940



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,
Tanasoiu Oana-Maria


Facter 4.0.28 is now available

Florin Dragos <florin@...>
 

Hello,

The Facter team has released a new version of facter: 4.0.28.

This release fixes a bug that was introduced in 4.0.27, which was yanked from rubygems.
Special thanks to smortex for finding and fixing the problem: #1938.

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,
Florin Dragos


Facter 4.0.27 is now available

Florin Dragos <florin@...>
 

Hello,

The Facter team is happy to announce the release of Facter 4.0.27.

Here is what changed:

New features

  • Networking facts for OSX #1929
  • FreeBSD disks and partitions facts #553
  • Use puppet AIO VERSION file to specify AIO version #549
  • EC2 facts for Windows #546
  • EC2 facts for Linux #544
  • External facts cache #541
  • Support for processors facts on *BSD #489

Bug fixes

  • Networking fact on linux should have logic for selecting IPs #1928
  • Facter sometimes pollutes the calling processes environment (race condition) #1932

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,
Florin Dragos


Re: Beaker Ownership RFC

Ewoud Kohl van Wijngaarden
 

On Tue, Jun 16, 2020 at 11:22:43AM -0700, Lucy Wyman wrote:
However, in practice I haven't
found issues there or things I missed. The majority of issues are in
related repositories.

Absolutely! This is echoed across the community. I have a note at the
bottom of the RFC under the heading "What about other Beaker-related
repositories?". We're starting with Beaker because it's the biggest pain
point, and plan to transfer ownership for Beaker-related repos to
interested parties with Beaker as a precedent. Would you or Vox be
interested in owning and maintaining beaker-hiera, beaker-hostgenerator,
and beaker-puppet?
I can't speak for others, but I would certainly like that. beaker-vagrant is another.

There is also a very strong control that everything has to go through
Puppet employees when it comes to a release.

Yes, that's absolutely true of this draft. We're happy to pin Beaker if it
breaks our pipelines, I think we're mostly nervous that it will break right
before a release. I'll discuss with affected teams about whether we'd like
a heads up + a day to run tests internally and pin, or if we're ok with
treating Beaker like any other upstream repo and pinning after release. I
don't think we expect releases to be gated on Puppet approval, but we might
like some courtesy time to pin without panic.
In general we should maintain compatibility according to semver so strict pinning should generally not be needed. Regressions should be dealt with by a bugfix release. Of course I understand the pain when this happens during a release, but IMHO it's not different from the constant CI runs for many different Puppet modules. Good code reviews and good regression tests in CI together with good communication are the solution to this. For example by giving a heads up that a release is planned.

I'd be fine with a group that has to ack a release and that group can contain Puppet employees but it shouldn't be limited to Puppet employees.

Based on this proposal, leaving it in the Puppetlabs namespace and just
adding select individuals as admins on the repos would serve the same
purpose.

We'd really like to move Beaker out of our namespace if possible, and
removing Puppet approval from the release process gives Vox more autonomy.
I hope that's ok?

On Tue, Jun 16, 2020 at 7:52 AM Trevor Vaughan <tvaughan@onyxpoint.com>
wrote:

I'm all for widening the scope of Beaker maintenance but I have to agree
with Ewoud that this seems like a Puppet project with a Vox name.

Based on this proposal, leaving it in the Puppetlabs namespace and just
adding select individuals as admins on the repos would serve the same
purpose.

Trevor

On Tue, Jun 16, 2020 at 9:18 AM Ewoud Kohl van Wijngaarden <
ewoud+voxpupuli@kohlvanwijngaarden.nl> wrote:

On Mon, Jun 15, 2020 at 08:10:46AM -0700, Lucy Wyman wrote:
Hi Vox!

First, thank you SO MUCH for everything you do, and for your interest in
maintaining Beaker. I've put together an RFC
<
https://docs.google.com/document/d/1AHcStgkg060YBLjLiat-3nVnU1ENTUtP8gHE_dhWHms/edit?usp=sharing

for transferring ownership and had it approved within Puppet, so we're
ready to have anyone from Vox who's interested read it over and discuss!
Please feel free to leave any comments, questions, or concerns either in
the document, this email thread, slack, or IRC and we can discuss. I will
also be at the next Vox meeting on Tuesday, June 23rd as well if there's
anything folks want to discuss in real-time.

Thanks so much! I hope everyone is staying well.
Hello Lucy,

As someone who does use beaker and is frustrated by the lack of its
maintenance, I'm certainly interested. However, I'm disappointed by the
proposal.

First of all, it only mentions the Beaker respository (which I assume is
https://github.com/puppetlabs/beaker). However, in practice I haven't
found issues there or things I missed. The majority of issues are in
related repositories. Like https://github.com/puppetlabs/beaker-hiera
which is archived, but the functionality is completely missing now. It
meantions it should be in beaker-puppet, but isn't. beaker-hostgenerator
the PRs are usually open for a month or 2 before seeing any response.

There is also a very strong control that everything has to go through
Puppet employees when it comes to a release. To me this is a big issue.
Vox Pupuli is IMHO its own organization and should (mostly) work
indepent. If you don't trust VP to manage it, then you shouldn't hand it
over. Note that only a small subset of people actually has control over
https://rubygems.org/profiles/voxpupuli. Most collaborators only rely on
automation when a tag is pushed.

So in short, I'd love to see active development on Beaker again but
think that the current proposal undermines the Vox Pupuli projects
integrity.

It would be my preference to go the open source way. Fully transfer the
projects and be maintainers via the meriocratic way.

If this is undesirable and control must be kept, then I'd suggest to
create a new organization on Github and transfer it there.



--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --




New release of puppet-jira to puppetforge?

Hugo Haakseth <hugo.haakseth@...>
 

Hi

I'm just wondering if it's possible to get a version of puppet-hiera with the latest ( 20 days ago ) changes in masterbranch to puppetforge?
Currently this module block stdlib and archive upgrades..

Regards
Hugo


Re: Beaker Ownership RFC

Lucy Wyman
 

However, in practice I haven't
found issues there or things I missed. The majority of issues are in
related repositories.

Absolutely! This is echoed across the community. I have a note at the bottom of the RFC under the heading "What about other Beaker-related repositories?". We're starting with Beaker because it's the biggest pain point, and plan to transfer ownership for Beaker-related repos to interested parties with Beaker as a precedent. Would you or Vox be interested in owning and maintaining beaker-hiera, beaker-hostgenerator, and beaker-puppet?

There is also a very strong control that everything has to go through
Puppet employees when it comes to a release.

Yes, that's absolutely true of this draft. We're happy to pin Beaker if it breaks our pipelines, I think we're mostly nervous that it will break right before a release. I'll discuss with affected teams about whether we'd like a heads up + a day to run tests internally and pin, or if we're ok with treating Beaker like any other upstream repo and pinning after release. I don't think we expect releases to be gated on Puppet approval, but we might like some courtesy time to pin without panic.

Based on this proposal, leaving it in the Puppetlabs namespace and just adding select individuals as admins on the repos would serve the same purpose.

We'd really like to move Beaker out of our namespace if possible, and removing Puppet approval from the release process gives Vox more autonomy. I hope that's ok?


On Tue, Jun 16, 2020 at 7:52 AM Trevor Vaughan <tvaughan@...> wrote:
I'm all for widening the scope of Beaker maintenance but I have to agree with Ewoud that this seems like a Puppet project with a Vox name.

Based on this proposal, leaving it in the Puppetlabs namespace and just adding select individuals as admins on the repos would serve the same purpose.

Trevor

On Tue, Jun 16, 2020 at 9:18 AM Ewoud Kohl van Wijngaarden <ewoud+voxpupuli@...> wrote:
On Mon, Jun 15, 2020 at 08:10:46AM -0700, Lucy Wyman wrote:
>Hi Vox!
>
>First, thank you SO MUCH for everything you do, and for your interest in
>maintaining Beaker. I've put together an RFC
><https://docs.google.com/document/d/1AHcStgkg060YBLjLiat-3nVnU1ENTUtP8gHE_dhWHms/edit?usp=sharing>
>for transferring ownership and had it approved within Puppet, so we're
>ready to have anyone from Vox who's interested read it over and discuss!
>Please feel free to leave any comments, questions, or concerns either in
>the document, this email thread, slack, or IRC and we can discuss. I will
>also be at the next Vox meeting on Tuesday, June 23rd as well if there's
>anything folks want to discuss in real-time.
>
>Thanks so much! I hope everyone is staying well.

Hello Lucy,

As someone who does use beaker and is frustrated by the lack of its
maintenance, I'm certainly interested. However, I'm disappointed by the
proposal.

First of all, it only mentions the Beaker respository (which I assume is
https://github.com/puppetlabs/beaker). However, in practice I haven't
found issues there or things I missed. The majority of issues are in
related repositories. Like https://github.com/puppetlabs/beaker-hiera
which is archived, but the functionality is completely missing now. It
meantions it should be in beaker-puppet, but isn't. beaker-hostgenerator
the PRs are usually open for a month or 2 before seeing any response.

There is also a very strong control that everything has to go through
Puppet employees when it comes to a release. To me this is a big issue.
Vox Pupuli is IMHO its own organization and should (mostly) work
indepent. If you don't trust VP to manage it, then you shouldn't hand it
over. Note that only a small subset of people actually has control over
https://rubygems.org/profiles/voxpupuli. Most collaborators only rely on
automation when a tag is pushed.

So in short, I'd love to see active development on Beaker again but
think that the current proposal undermines the Vox Pupuli projects
integrity.

It would be my preference to go the open source way. Fully transfer the
projects and be maintainers via the meriocratic way.

If this is undesirable and control must be kept, then I'd suggest to
create a new organization on Github and transfer it there.





--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --


Re: Beaker Ownership RFC

Trevor Vaughan
 

I'm all for widening the scope of Beaker maintenance but I have to agree with Ewoud that this seems like a Puppet project with a Vox name.

Based on this proposal, leaving it in the Puppetlabs namespace and just adding select individuals as admins on the repos would serve the same purpose.

Trevor


On Tue, Jun 16, 2020 at 9:18 AM Ewoud Kohl van Wijngaarden <ewoud+voxpupuli@...> wrote:
On Mon, Jun 15, 2020 at 08:10:46AM -0700, Lucy Wyman wrote:
>Hi Vox!
>
>First, thank you SO MUCH for everything you do, and for your interest in
>maintaining Beaker. I've put together an RFC
><https://docs.google.com/document/d/1AHcStgkg060YBLjLiat-3nVnU1ENTUtP8gHE_dhWHms/edit?usp=sharing>
>for transferring ownership and had it approved within Puppet, so we're
>ready to have anyone from Vox who's interested read it over and discuss!
>Please feel free to leave any comments, questions, or concerns either in
>the document, this email thread, slack, or IRC and we can discuss. I will
>also be at the next Vox meeting on Tuesday, June 23rd as well if there's
>anything folks want to discuss in real-time.
>
>Thanks so much! I hope everyone is staying well.

Hello Lucy,

As someone who does use beaker and is frustrated by the lack of its
maintenance, I'm certainly interested. However, I'm disappointed by the
proposal.

First of all, it only mentions the Beaker respository (which I assume is
https://github.com/puppetlabs/beaker). However, in practice I haven't
found issues there or things I missed. The majority of issues are in
related repositories. Like https://github.com/puppetlabs/beaker-hiera
which is archived, but the functionality is completely missing now. It
meantions it should be in beaker-puppet, but isn't. beaker-hostgenerator
the PRs are usually open for a month or 2 before seeing any response.

There is also a very strong control that everything has to go through
Puppet employees when it comes to a release. To me this is a big issue.
Vox Pupuli is IMHO its own organization and should (mostly) work
indepent. If you don't trust VP to manage it, then you shouldn't hand it
over. Note that only a small subset of people actually has control over
https://rubygems.org/profiles/voxpupuli. Most collaborators only rely on
automation when a tag is pushed.

So in short, I'd love to see active development on Beaker again but
think that the current proposal undermines the Vox Pupuli projects
integrity.

It would be my preference to go the open source way. Fully transfer the
projects and be maintainers via the meriocratic way.

If this is undesirable and control must be kept, then I'd suggest to
create a new organization on Github and transfer it there.





--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --


Re: Beaker Ownership RFC

Ewoud Kohl van Wijngaarden
 

On Mon, Jun 15, 2020 at 08:10:46AM -0700, Lucy Wyman wrote:
Hi Vox!

First, thank you SO MUCH for everything you do, and for your interest in
maintaining Beaker. I've put together an RFC
<https://docs.google.com/document/d/1AHcStgkg060YBLjLiat-3nVnU1ENTUtP8gHE_dhWHms/edit?usp=sharing>;
for transferring ownership and had it approved within Puppet, so we're
ready to have anyone from Vox who's interested read it over and discuss!
Please feel free to leave any comments, questions, or concerns either in
the document, this email thread, slack, or IRC and we can discuss. I will
also be at the next Vox meeting on Tuesday, June 23rd as well if there's
anything folks want to discuss in real-time.

Thanks so much! I hope everyone is staying well.
Hello Lucy,

As someone who does use beaker and is frustrated by the lack of its maintenance, I'm certainly interested. However, I'm disappointed by the proposal.

First of all, it only mentions the Beaker respository (which I assume is https://github.com/puppetlabs/beaker). However, in practice I haven't found issues there or things I missed. The majority of issues are in related repositories. Like https://github.com/puppetlabs/beaker-hiera which is archived, but the functionality is completely missing now. It meantions it should be in beaker-puppet, but isn't. beaker-hostgenerator the PRs are usually open for a month or 2 before seeing any response.

There is also a very strong control that everything has to go through Puppet employees when it comes to a release. To me this is a big issue. Vox Pupuli is IMHO its own organization and should (mostly) work indepent. If you don't trust VP to manage it, then you shouldn't hand it over. Note that only a small subset of people actually has control over https://rubygems.org/profiles/voxpupuli. Most collaborators only rely on automation when a tag is pushed.

So in short, I'd love to see active development on Beaker again but think that the current proposal undermines the Vox Pupuli projects integrity.

It would be my preference to go the open source way. Fully transfer the projects and be maintainers via the meriocratic way.

If this is undesirable and control must be kept, then I'd suggest to create a new organization on Github and transfer it there.


Beaker Ownership RFC

Lucy Wyman <lucy@...>
 

Hi Vox!

First, thank you SO MUCH for everything you do, and for your interest in maintaining Beaker. I've put together an RFC for transferring ownership and had it approved within Puppet, so we're ready to have anyone from Vox who's interested read it over and discuss! Please feel free to leave any comments, questions, or concerns either in the document, this email thread, slack, or IRC and we can discuss. I will also be at the next Vox meeting on Tuesday, June 23rd as well if there's anything folks want to discuss in real-time.

Thanks so much! I hope everyone is staying well.


Re: Join Voxpupuli Group on Github

Alex Fisher
 

Hi Florian!

Would you like to stop by #voxpupuli on freenode IRC or the #voxpupuli channel on the puppet community slack?  Hopefully we can get some of your recent (and not so recent PRs) progressed and merged.

Looking forward to seeing you soon,
Alex


Join Voxpupuli Group on Github

Faltermeier, Florian <Florian.Faltermeier@...>
 

Dear Voxpupuli Community,

 

is it possible to join your voxpupuli group as a member on Github?

My Github account is: florianfa

 

Thank you very much

 

Florian

 


Facter 4.0.24 is now available

Andrei Filipovici <andrei.filipovici@...>
 

Hello,

The Facter team is happy to announce the release of Facter 4.0.24



Here is what changed:

Added

  • (FACT-2605) Add vmware resolver #525
  • (FACT-2604) Add virt-what resolver #523
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,
Andrei Filipovici


Facter 4.0.22 is now available

Bogdan Irimie
 

Hello,

The Facter team is happy to announce the release of Facter 4.0.22
rospberry_parade.gif

Here is what changed:

Added

  • (FACT-2603) Detect virtual on GCE vms #521
  • (FACT-2602) Add docker/Lxc resolver for Linux #520
  • (FACT-2615) Add Solaris mountpoints fact #515
  • (FACT-2532) Add Aix nim_type fact #513
  • (FACT-2183) Add Solaris's uptime legacy facts #511

Fixed

  • (FACT-2617) Fix for tests/external_facts/external_fact_stderr_messages_output_to_stderr.rb #522
  • (FACT-2523) Fix for tests/external_facts/non_root_users_default_external_fact_directory.rb #518
  • (FACT-2522) Fix for tests/external_facts/fact_directory_precedence.rb #517
  • (FACT-2521) Fix for tests/external_facts/external_fact_overrides_custom_fact_with_10000_weight_or_less.rb #514
  • (FACT-2525) Fix for tests/options/color.rb #512


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,
Bogdan Irimie


Facter 4.0.21 is now available

Oana Tanasoiu <oana.tanasoiu@...>
 

Hello,

The Facter team is happy to announce the release of Facter 4.0.21


Here is what changed:

Added

  • (FACT-2599) Run GitHub Actions on Ubuntu 16 and Osx 10 #497
  • (FACT-2247) Add networking fact for linux #496
  • (FACT-2515) Define custom fact groups in facter.conf #491
  • (FACT-2557) Add rake task for generating list of facts for specified OS #488
  • Add os.release facts on FreeBSD #485
  • (FACT-2235) Add Aix processors fact #483
  • (FACT-2569) Run acceptance tests on Ubuntu GitHub actions #477
  • (FACT-2553) Quote special string in YAML format #471
  • (FACT-2517) Open3 wrapper for executing system calls #469

Fixed

  • (FACT-2533) Fix for tests/facts/partitions.rb #507
  • (FACT-2531) Fix for tests/facts/validate_file_system_size_bytes.rb #500
  • (FACT-2582) Date and Time in external YAML fact is not loaded #499
  • (FACT-2556) Refactor existing facts to use the new OS hierarchy #486


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,
Tanasoiu Oana-Maria


PDK 1.18.0 now available

Jesse Scott
 

Hello!

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

Highlights from the 1.18.0 release include:

- Added a new, control-repo specific validator for `environment.conf` files.
- Added `pdk set config` and `pdk remove config` subcommands.

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

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

Thanks!

21 - 40 of 371