Forem: David Sandilands

Lets get our facts straight

David Sandilands — Thu, 13 Mar 2025 16:03:24 +0000

During some recent user discussions there was some confusion on some logging coming from a pdk test unit run. See some example output below

root@rocky8-320 test_320 $ pdk test unit
pdk (INFO): Using Ruby 3.2.3
pdk (INFO): Using Puppet 8.6.0
[✔] Preparing to run the unit tests.
/opt/puppetlabs/pdk/private/ruby/3.2.3/bin/ruby -I/opt/puppetlabs/pdk/share/cache/ruby/3.2.0/gems/rspec-core-3.13.0/lib:/opt/puppetlabs/pdk/share/cache/ruby/3.2.0/gems/rspec-support-3.13.1/lib /opt/puppetlabs/pdk/share/cache/ruby/3.2.0/gems/rspec-core-3.13.0/exe/rspec --pattern spec/\{aliases,classes,defines,functions,hosts,integration,plans,tasks,type_aliases,types,unit\}/\*\*/\*_spec.rb --format progress
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"Rocky", :operatingsystemrelease=>"/^8/", :hardwaremodel=>"x86_64"}, using v4.5.0 instead
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"OracleLinux", :operatingsystemrelease=>"/^7/", :hardwaremodel=>"x86_64"}, using v4.2.2 instead
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"RedHat", :operatingsystemrelease=>"/^8/", :hardwaremodel=>"x86_64"}, using v4.5.2 instead
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"Scientific", :operatingsystemrelease=>"/^7/", :hardwaremodel=>"x86_64"}, using v4.2.2 instead
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"Debian", :operatingsystemrelease=>"/^10/", :hardwaremodel=>"x86_64"}, using v4.5.0 instead
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"Ubuntu", :operatingsystemrelease=>"/^18\\.04/", :hardwaremodel=>"x86_64"}, using v4.5.0 instead
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"windows", :operatingsystemrelease=>"\"2019\"", :hardwaremodel=>"x86_64"}, using v4.4.0 instead
No facts were found in the FacterDB for Facter v4.5.1 on {:operatingsystem=>"windows", :operatingsystemrelease=>"\"10\"", :hardwaremodel=>"x86_64"}, using v4.4.0 instead
Run options: exclude {:bolt=>true}
..........

Coverage Report:

Total resources:   1
Touched resources: 0
Resource coverage:  0.00%

Untouched resources:
  Notify[Hello world]


Finished in 0.50081 seconds (files took 12.36 seconds to load)
10 examples, 0 failures

root@rocky8-320 test_320 $

This raised questions

Isn't operatingsystemsrelease and operatingsystem legacy facts?
Why couldn't it find Facter at 4.5.1?
Why are some OS having to use much older facter 4.2.2 and 4.4.0?

So to answer these questions lets understand what PDK is doing when it calls PDK test unit and runs its rspec tests. There are two particularly useful projects from Vox Pupuli https://github.com/voxpupuli/facterdb, providing the fact sets for different OS during testing and https://github.com/voxpupuli/rspec-puppet-facts which provide the magic behind the loop you see in the templated rspec tests:

on_supported_os(test_on).each do |os, os_facts|

This loop essentially reads your metadata.json file of what OS are supported by your module which looks something like this:

 "operatingsystem_support": [
    {
      "operatingsystem": "RedHat",
      "operatingsystemrelease": [
        "7",
        "8",
        "9"
      ]
    },
    {
      "operatingsystem": "Windows",
      "operatingsystemrelease": [
        "10",
        "2012",
        "2012 R2",
        "2016",
        "2019",
        "2022"
      ]
    },

So that brings us to the first question aren't operatingsystem and operatingsystemrelease legacy facts? Well yes they were but if you look at the documentation this this just the parameter names for the metadata.json file to specify what OS and what versions you are supporting.

This loop then runs the get_facts function from FacterDB for each OS and each version your module supports. If you take a look at some of the data in FacterDB you will see in the facts folder set of folders of different Facter Versions and then files named by OS and Version such as this for Redhat 9 for Facter 4.11 https://github.com/voxpupuli/facterdb/blob/master/facts/4.11/redhat-9-x86_64.facts

Looking at the output below we see this produces an output of facts which you may notice are missing some facts which are overly specific or have had the node name updated to generic name.

This allows you to have sample facts for each OS release on different versions of facter.

So why couldn't it find Facter at 4.5.1 (the gem version PDK was using during these tests) and had to use something else? Well if you first notice the folder structure only goes down to 4.5 and if we first look at Rocky 8 which is in the 4.5 folder we see the facterversion in the file is

"facterversion": "4.5.0"

So the person who provided this data ran it in facter 4.5.0 hence this message was just a warning that there is a small missmatch but its purely informational and for that level of minor difference it unlikely to affect testing.

Now looking at Rhel 7 which could only find 4.2.2 well we can see its not in the folder and this is because Rhel 7 exited support at this point and 4.2 was the last valid supported version of facter for it.

So hopefully this has made this process a bit clearer and made you appreciate how useful these projects are too.

Lets get started with Puppet Core

David Sandilands — Tue, 25 Feb 2025 10:16:11 +0000

So you have seen Puppet Core is available as a customer or on a developer license and you now want to get hold of the packages. If you are a user with more than 25 nodes make sure you speak to sales.

The first step is to make sure you have signed the EULA at https://forge.puppet.com/eula , in this case I have signed up as a developer user.

Now you need to create a forge API key, first make sure you have multifactor authentication enabled in settings.

Then when you create the key it will only be displayed once so I would recommend storing it in an appropriate secure secret store, I am using 1password for this demo.

Now that you have the key, you can see in the install instructions various locations for Puppet core content depending on your OS install type.

I will show examples of using Alma Linux 9 and Windows 11.

For Alma this is a simple job of installing the release package

[root@DESKTOP-E3QS517:~]# yum install https://yum-puppetcore.puppet.com/public/puppet8-release-el-9.noarch.rpm
Last metadata expiration check: 2:08:56 ago on Mon Feb 24 14:37:10 2025.
puppet8-release-el-9.noarch.rpm                                                                                                                                                                                                              3.6 kB/s | 8.2 kB     00:02
Dependencies resolved.
=============================================================================================================================================================================================================================================================================
 Package                                                              Architecture                                                Version                                                            Repository                                                         Size
=============================================================================================================================================================================================================================================================================
Installing:
 puppet8-release                                                      noarch                                                      10.4.0-0.el9                                                       @commandline                                                      8.2 k

Transaction Summary
=============================================================================================================================================================================================================================================================================
Install  1 Package

Total size: 8.2 k
Installed size: 2.0 k
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                                                                                                                                                     1/1
  Installing       : puppet8-release-10.4.0-0.el9.noarch                                                                                                                                                                                                                 1/1
warning: Unable to get systemd shutdown inhibition lock: Could not activate remote peer.

  Verifying        : puppet8-release-10.4.0-0.el9.noarch                                                                                                                                                                                                                 1/1

Installed:
  puppet8-release-10.4.0-0.el9.noarch

Complete!
[root@DESKTOP-E3QS517:~]# vi /etc/yum.repos.d/puppet8-release.repo

and then adding your forge API key to the repo configuration. Don't change the username it's supposed to be forge-key.

[puppet8]
name=Puppet 8 Repository el 9 - $basearch
baseurl=https://yum-puppetcore.puppet.com/puppet8/el/9/$basearch
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-2025-04-06-puppet8-release
enabled=1
gpgcheck=1

## Add authentication here by uncommenting and filling in values

#username=forge-key
#password=<api_key>

You can then search the packages to make sure the packages are visible.

[root@DESKTOP-E3QS517:~]# yum search puppet
Last metadata expiration check: 2:46:27 ago on Mon Feb 24 14:37:34 2025.
======================================================================================== Name & Summary Matched: puppet =========================================================================================
puppet-agent.x86_64 : The Puppet Agent package contains all of the elements needed to run puppet, including ruby and facter.
puppet8-release.noarch : Release packages for the Puppet 8 repository
puppetdb.noarch : Puppet Labs puppetdb
puppetdb-termini.noarch : Termini for puppetdb
puppetserver.noarch : Puppet Labs puppetserver
============================================================================================ Summary Matched: puppet ============================================================================================

For Windows I used the curl command and I am using the 1Password CLI to allow me to read in my stored forge key. This simply downloads the agent.

curl -J -O -u forge-key:$(op read op://Employee/puppetcorekey/password) 'https://artifacts-puppetcore.puppet.com/v1/download?os_name=windows&os_version=11&version=8.11.0&os_arch=x64'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 43.6M  100 43.6M    0     0  62.5M      0 --:--:-- --:--:-- --:--:-- 62.6M
 ls .\puppet-agent-8.11.0-x64.msi

    Directory: C:\Users\david.sandilands

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---          24/02/2025    16:25       45749760 puppet-agent-8.11.0-x64.msi

So simple as that we now have the Puppet core packages secured with the forge keys. Let us know if there any further details you are looking for with Puppet Core.

Louis, I think this is the beginning of a beautiful friendship

David Sandilands — Thu, 23 Jan 2025 10:34:40 +0000

There have been a lot of concerns and questions about Puppet and the Community over the past couple of months since the changes were announced . It has taken Perforce and the Community time to work out how to meet the Communities need for autonomy, Perforces business needs and legal responsibilities for items like trademark, all while ensuring the rich Puppet ecosystem of content and tools remain compatible.

OpenVox have created what we would describe as a soft fork, where they create a new name space and project name OpenVox but the use of 'puppet'; in forked source code follows Apache 2.0 licensing with the intent to retain compatibility, and attribute the Puppet trademark appropriately to avoid brand confusion. Simply this ensures binaries, libraries, etc do not need renamed and ensures Perforces responsibility as a trademark holder is met.

To ensure this new partnership works well we will be taking a number of steps in order to guarantee long term interoperability to the benefit of all current and future Puppet users.

Perforce and the Community will partner together on a language steering group to ensure we continues to develop the language specification and ensure ecosystem compatibility.
Everyone will have access to EULA signed builds from Perforce for development purposes which will be released on a 6 week cycle.
We will be revitalizing our trusted Contributor and Champions programs while also ensuring our own staff are enabled to contribute
An event plan will be created to help our community and customers know where they can come and collaborate with us

We congratulate OpenVox on their first release and look forward to shortly releasing Puppet Core which will offer hardened binaries with bug and vulnerability support to give customers a more accessible level for enterprise support.

Look out for further announcements and hopefully we will see many of you at Cfgmgmt Camp in two weeks

Puppet Community Townhall Recap

David Sandilands — Wed, 18 Dec 2024 18:58:18 +0000

I would like to thank everyone who joined us for our Community Townhall. We appreciate the questions, concerns, and feedback.

To summarize the call, we clarified the changes and the reasons behind them. We acknowledged Puppet’s maturity as a product, the rising cost to secure and maintain open-source Puppet (OSP) and need to balance downstream priorities required of Enterprise customers while reinvesting in the freedom of the community to grow OSP under the Apache 2.0 license.

We also communicated our go-forward plans to formalize programs that support and recognize Puppet contributors and provide support for community-run regional user groups. We recognize that these programs previously existed, but we are looking to gather input from the community to ensure these programs are re-launched in a meaningful way. We communicated plans to discuss this live with community members at cfgmgmt camp.

After a few brief slides, we opened to the floor for questions. Here is a summary of the Q&A session. We didn’t have time to fully address all the questions asked during the live session, so I have provided additional clarification in this blog summary.

Community Ownership – Several questions & concerns were raised over the location and ownership of the open-source repositories. We addressed that the repos would remain in the puppetlabs name space which Perforce would continue to fund, including covering costs for contributor licenses and build pipelines/infrastructure.

As far as ownership goes, Perforce communicated a plan that grants ownership of the following to the collective community under the Apache 2.0 license:

• Co-author the source code of the project
• Approve commits / changes
• Maintain security fixes / defect fixes
• Create binaries, packages, Gems
• Create/Maintain Modules in a compatible way

Puppet & Perforce have historically owned this. In this new community-led model, Perforce is a part of the collective community, not the sole owners or gatekeepers of the community.

Control and decision making - It was asked how conflicts would be resolved going forward, and who would have majority control. Community members expressed concern with Perforce having too much power. Our view is that the collective community would have to work together to establish the correct process, structure, and bylaws. Mechanisms, such as the language steering committee, would allow us to work out ways that ensure compatibility and interoperability for the Puppet ecosystem. We do not aim to have majority stake, just equal representation as other community members. Our goal is to provide support for the community in this new model, and we still plan to contribute.

Contributions v Reviews - We discussed the reduction in contributions by community members over the past several years. Attendees indicated that this was a result of the infrequent and slow review process by the Puppet and Perforce team. The Perforce team agreed and acknowledged this as part of the prioritization problem we have been experiencing – a leading reason why we want to remove ourselves as a gatekeeper. In the new model, Perforce is no longer a gatekeeper. The collective community would have the ability to approve commits and changes.

Hardened packages - Questions were asked about the hardened OSP packages available in Perforce’s private repository, specifically what hardening will be provided. Perforce has a well-established, standardized set of processes and tools for product hardening that we apply consistently across our commercial offerings. Over time, we’ve developed a proven methodology that includes industry-leading security assessments, code reviews, and penetration testing procedures. Our approach involves leveraging a vetted toolchain for security scanning and adhering to a rigorous security checklist throughout the development lifecycle. By following these standardized practices, we ensure that Perforce commercial products pass thorough hardening measures before reaching our customers. The hardened OSP packages are no exception. We will provide further details, including SLAs, when the offering launches in early 2025.

We also confirmed that the community will have free access to the hardened OSP packages in the Perforce private repository under the terms of 25 node limited development license.

Cnfgmgmt camp geography - It was highlighted that many members would not be able to make cnfgmgmt camp and we agreed to investigate options to facilitate remote voting / viewing. We will ensure that the broader community has a chance to weigh in and vote.

Trademark - It was asked if the Puppet trademark could be used in the community project for various naming purposes. In short, the Perforce team said “no”. We understand that the open-source community is interested in using our trademark, and we appreciate the community’s enthusiasm for Puppet. However, our trademark represents a significant investment in our brand, reputation, and the quality we guarantee to our customers.

This choice isn’t a reflection on the community’s efforts or intentions. It is simply a matter of preserving the integrity of the Puppet brand and ensuring that any products or materials bearing the Puppet name continue to meet the criteria we have established. We appreciate your understanding and respect for our position.

Again, I would like to thank everyone for taking part in the Puppet Community Town Hall. Many of the concerns raised reflect the difficulty of having community contributions overlayed into a release process that Puppet and Perforce have fully controlled. We understand that this announcement and our intent to remediate these concerns can have the adverse effect of raising more questions than answers, but we are eager to find a path forward through ongoing conversations with the Puppet community. We believe that we share a common goal for increased adoption and success of Puppet across a diverse range of customer needs.

For those that could not make it, the recording is available. (Passcode: E4^x02M8)
Please reach out to us on Puppet’s Community slack or at puppet-community-questions@perforce.com with any questions.

Forge Compatibility Reports for module management

David Sandilands — Mon, 16 Dec 2024 14:00:37 +0000

It was the moment I dreaded: my Puppet modules would be running perfectly, and then a Puppet upgrade, new module, or module update would break the harmony. I would need to scramble to work out dependencies between modules and make sure everything could be brought up to date and be compatible.

This process often required a giant spreadsheet, where I would slowly copy out details from the Forge and check them over and over while I negotiated with my team about which versions we had to stick for certain requirements. And even while this was happening, I still had to watch out to see if module upgrades had new decencies or worse deprecations — then I would need to revisit the Sudoku-like spreadsheet again.

The great news is this is no longer needed — with the new Compatibility Report, the Forge does the hard work for us.

Starting out, we need to provide a baseline for the compatibility report, this can either be done from your existing module download information or by providing a Puppetfile. See enabling download reporting if you want to set up your module download information.

The advantage of providing a Puppetfile is it gives you the flexibility to try different configurations without worrying about affecting your current download information.

Once we have chosen our download information or uploaded a Puppetfile, we can then select the version of PE or Puppet we want to baseline to. This is especially useful for users who want to catch up this include versions like 6 and 7 and PE 2019 and 2021.

We now have a compatibility report highlighting modules that need updates, where dependencies have been added, deprecations, and incompatibilities.

We can also examine the changes in the module version suggested by clicking see changes to the right of the suggest version.

A new Puppetfile containing the suggestions and new dependencies can be downloaded clicking the download Puppetfile button on the top right of the report. Incompatibilities will be left at their original version.

If you (like me) have that team that insists they need to pin to a certain version of a module, you can select modules and see which version would be compatible for the Puppet/PE version you are targeting

Then generate a specific report, in this case we can actually immediately see the module version I have chosen for Apache can not be made compatible with the other dependency requirements in the Puppetfile.

It’s worth noting that you can keep up to 25 reports, so you can experiment and compare reports.

Beyond the core use case of upgrading Puppet, the report also gives you the ability to test adding modules to a Puppet file, update a module version, or removing modules.

So a big “thank you!” to the Forge team and grateful farewell to that awful spreadsheet!”

https://help.puppet.com/forge/current/Content/intro/comp_rept_overview.htm

Open Source Puppet Survey

David Sandilands — Thu, 11 Jul 2024 11:30:16 +0000

Hello all,

We value your input and as we investigate future roadmap initiatives for Open Source Puppet, we'd like to learn more about your experience with Open Source Puppet, and your views and opinions on a couple of important related topics.

This survey will take just approximately 7 minutes of your time and will remain open until July 25th.

Past feedback from our Open Source users has been incredibly helpful, and we sincerely appreciate your continued participation. Your feedback helps us understand your needs better and guides our decision making on current and future offerings for our Open Source user base.

Open Source Puppet Survey

Puppet certificate renewals

David Sandilands — Thu, 06 Jun 2024 12:47:22 +0000

After a number of customer sessions it was apparent that there were a number of places and tools which could be used to handle Puppet certificates and it would be good to have a written summary to be able to step through. This article aims to give a summary of what we need to do to keep Puppet certificates in date.

In summary:

We must understand when our Console Certificate and SAML certificates will expire and renew it in advance (PE only)
We must understand when our Certificate Authority (CA) will expire and renew it in advance
When we renew our CA we must distribute that new CA to both clients and integrations.
Separately all clients including the Primary itself have an agent signed certificate which will expire separately and must be renewed in advance.

Console and SAML expiry

For a Puppet generated generated console and SAML certificates expiry is every 824 days and the articles [regenerate console certificate],(https://www.puppet.com/docs/pe/latest/regenerate_console_cert)
covers how to check the expiry date as well as delete the current console certificate and replace with a Puppet run. While regnerate SAML certificate covers the same for SAML if you have configured it.

If you are using a custom console certificate ultimately you will replace the expiring certificate using the custom ssl certificate for console article.

CA expiry.

For Primaries built pre-Puppet 6 this would be a 5 year expiry period, which we would extend now to 20 years as Puppet 6 and onwards does.

This expiry date is visible at https://primary.example.com/#/certificates/certs ,using the pe_status_check module S0005 fact status check or using the CA_extend module check_ca_expiry task.

When it needs renewed we recommend using the CA_extend module extend_ca_cert plan

Following this the new CA should then be distributed to all agents using CA_extend module upload_ca_cert plan or by simply running a script on each agent which deletes / moves the old CA at C:\ProgramData\PuppetLabs\puppet\etc\ssl\certs\ca.pem or /etc/puppetlabs/puppet/ssl/certs/ca.pem depending on nix or Windows platform and runs puppet agent -t. This will request the new CA from the Puppet primary.

Integrations

For CD4PE steps 4 to 6 should be followed in CD4PE manually configure PE integration to obtain and copy and paste the new CA into the Puppet integration page

Signed agents

We would recommend upgrading to Puppet 8 which would automate this step as shown on the blog article but agents by default pre-Puppet 8 will have a 5 years expiry. There are multiple ways to search agents about to expire. The CA_extend module has a check_agent_expiry task. (This will report a default period of within 3 months but can be adjusted), the pe_status_check module has AS001 fact status check, which combined with a PQL search will allow you to check for all agents expiring. As per doc example puppet query 'inventory[certname] { facts.agent_status_check.AS001 = false }'

The command to renew agents can be run via puppet infra run regenerate_agent_certificate which can also be run via the enterprise task plan enterprise_tasks::agent_cert_regen and both can be fed by a query such as puppet plan run enterprise_tasks::agent_cert_regen agent=$(puppet query 'inventory[certname] { facts.agent_status_check.AS001 = false }' \| jq -r '.[].certname' \| paste -sd, -) master=$(puppet config print certname)

Hopefully this has pulled together all the information you need to keep ahead of certificate expiry and put in place suitable automation.

Selecting targets for plans in Puppet Enterprise

David Sandilands — Mon, 13 Mar 2023 17:41:14 +0000

This article was previously published on the Puppet blog by Steve Axthelm.

Do you author plans for Puppet Enterprise? Looking for ways to improve them? Read on!

The Puppet Plan language allows a variety of methods to pick targets. In this article we will explore two of these methods (TargetSpec parameters and PuppetDB queries) and how plan authors can employ the latter to:

Improve the user experience of running the plans.
Reduce input errors.
Restrict the scope of nodes that the plan can execute against.

Note: the following examples assume that you are running against targets that have the Puppet agent installed. You can achieve similar results for targets that are not running the Puppet agent by gathering facts with the facts plan.

TargetSpec parameters

The most basic target input a plan can have is a parameter that is a TargetSpec:

plan test::targets(
  TargetSpec $nodes_to_target,
){
  run_command("whoami", $nodes_to_target)
}

Users running the plan on the command line can then supply the targets through an inventory file, a list of FQDNs (fully qualified domain names), etc., and Puppet Enterprise Console users will be presented with a plain text input where they can enter FQDNs.

This is very flexible, but when authoring plans that other users will run, this much flexibility is often neither required nor desired, and also introduces the possibility for entry error. General user experience guidelines include error prevention when possible, so let's take a look at an alternative method for target input.

Using Enum Parameters and PuppetDB Queries

Using Enum type parameters is a great way to decrease the chances of user input errors. We could hard-code the targets into the plan and allow users to choose a set of targets. This would solve for user entry errors, but it would be fragile. We can specify targets in a more robust manner by using PuppetDB queries. Perhaps we have an application monitoring team that watches over web servers, load balancers and database servers. We can provide them with a quick way to select the types of hosts on which they are interested in running a task. PuppetDB queries are very flexible and can query for hosts using a variety of methods.

This plan takes a server_type parameter, queries all targets that fit the server_type profile through a PuppetDB query that checks if they have Apache, Haproxy, or Postgresql::Server classes applied to the hosts, and returns the last boot time for each host.

plan server_team::check_boot_time(
  Enum['Webservers', 'Balancers', 'Database'] $server_type,
){
  $server_type_query = case $server_type {
    'Webservers': { 'resources[certname] { type = "Class" and title = "Apache" }' }
    'Balancers': { 'resources[certname] { type = "Class" and title = "Haproxy" }' }
    'Database': { 'resources[certname] { type = "Class" and title = "Postgresql::Server" }' }
  }

  $server_type_results = puppetdb_query($server_type_query)
  $server_type_targets = $server_type_results.map |$r| { $r["certname"] }

  run_task("reboot::last_boot_time", $server_type_targets)
}

Command line interface (CLI) users can then run the plan with puppet plan run server_team::check_boot_time server_type=<value> and Puppet Enterprise Console users are presented with a select form control where they can choose the type:

This is a big improvement in user experience for the users who will run the plan and it also bakes in limited scope with respect to which nodes the plan can be run against. Trusted facts can also be employed in the queries to make the scope limiting more secure. This plan takes two parameters, rhel_major_version, and trusted_domain, constructs a PuppetDB query from those using facts and trusted facts, and then simply echoes out the trusted_domain for each host returned from the query.

plan server_team::echo_trusted_domain(
  Enum['6', '7', '8'] $rhel_major_version,
  Enum['vm', 'com', 'net'] $trusted_domain,
){
  $target_query = "trusted.domain = '$trusted_domain' and facts.os.family = 'RedHat' and facts.os.release.major = '$rhel_major_version'"

  $target_query_result = puppetdb_query("inventory[certname] { $target_query }")
  $command_targets = $target_query_result.map |$r| { $r["certname"] }

  run_command("echo $trusted_domain", $command_targets)
}

CLI users can run the plan with:

puppet plan run server_team::echo_trusted_domain rhel_major_version=<value> trusted_domain=<value>

And Puppet Enterprise Console users will be presented with select form controls for the parameters:

If the user supplies a value for either of the parameters that are not one of the enumerated options, an error will be thrown:

puppet plan run server_team::echo_trusted_domain rhel_major_version=7 trusted_domain=info

{
  "kind": "bolt/pal-error",
  "msg": "test::targets: parameter 'trusted_domain' expects a match for Enum['com', 'net', 'vm'], got 'info'",
  "details": {
  }
}

This ensures that users who run your plans will be able to supply only the parameter values you expect.

While the plans presented are simple in nature, hopefully they will spark some ideas for how you can improve the experience of the users who run plans that you author.

Learn More

Learn more about orchestrating workflows with Bolt plans.
Learn more about Bolt plans in Puppet Enterprise.