Overview of PuppetDB

Contributing to PuppetDB

Patches from third parties are necessary to keep the puppet amazing. Simply said, we are unable to access the vast array of platforms and settings needed to execute puppet. Contributors need to go by a few rules in order to have a chance of staying on top of things. Let's look at the fundamental commands for that.

Prerequisites

• Jira account
• GitHub account
• If a ticket doesn't already exist, create one for your problem.
• If the problem is a bug, make sure to include instructions on how to reproduce it.
• Fill down the earliest version that you are aware of having the problem.
• Fork the repository on GitHub.

Making changes 

1. Establish the topic branch upon which you will build your study (usually the main branch).
2. Commit logical units to memory.
3. Before committing, use git diff —check to check for extraneous whitespace.
4. Verify that your commit messages follow the correct format.
5. Verify that the relevant tests for your changes have been added.
6. Run each test to ensure that nothing else was unintentionally broken.

Testing

Using the integrated sandbox harness is the simplest approach to run the tests until you need to do it frequently. This should work if you only want to compare some modifications to "all the standard tests" (assuming you're not hosting a server on port 34335):

$ ext/bin/test-config --set pgport 34335
$ ext/bin/test-config --reset puppet-ref
$ ext/bin/test-config --reset puppetserver-ref
$ ext/bin/run-normal-tests

This will execute the internal, external, and integration tests, and in some circumstances, this may be all you require.

When utilizing the sandbox, you can either select a default or specify the PostgreSQL port it should use by passing the –pgport PORT parameter to each applicable test invocation.

Submitting changes 

1. Firstly, acknowledge the Contributor License Agreement.
2. In your fork of the repository, push your modifications to a subject branch.
3. Submit a pull request to the puppetlabs organization's repository.
4. Add a note to your Jira ticket indicating that your code submission is complete and ready for review (Status: Ready for Merge).
5. In the ticket, include a link to the pull request.
6. We anticipate responses within two weeks of receiving input. If there has been no progress on the pull request for two weeks, it might be closed.

PuppetDB: Release notes

In this section of the blog, we will see different released versions of Puppet. 

PuppetDB 7.11.1

It was released on September 14, 2022. 

Version 42.4.1 of the org. postgresql/postgresql driver has been released to address CVE-2022-31197, a risk for SQL injection that, according to the CVE report, can only be exploited if an attacker has complete control over the database and can change relevant tables' relevant column names to have "malicious" ones.

PuppetDB 7.11.0

It was released on August 2, 2022.

its fresh attributes are When log-queries are set to true, query logging has improved. Now that queries are logged with their UUIDs before they are parsed, it is simpler to troubleshoot PQL parsing problems. 

The bugs fixed are the following: 

• Fixed an issue that allowed valid queries employing the > operator inside of an extract clause to fail. This bug was introduced in 6.19.0 and 7.10.1. The patch also resolves a UX problem wherein a cryptic error would appear if the incorrect number of arguments were provided in a ~> clause.
• 6.21.0 and 7.10.1 bugs that led to upgrading failures with PostgreSQL hot standbys have been fixed. To get around the issue, the way the jit is disabled has been altered.

PuppetDB 7.10.0

It was released on March 22, 2022.

• Its new features are as follows:
  On startup, PuppetDB will no longer do garbage collection. The amount of time needed before PuppetDB starts taking commands and queries may be significantly shortened as a result.
• Path GC is currently limited to running once every 24 hours by default. In exchange for a possible slower reaction to the absence of individual fact pathways, this should generally be substantially less expensive.
• During the initial sync, PuppetDB will no longer process incoming instructions. This might enable the sync to complete more rapidly, cutting down on starting time (Puppet Enterprise only).

The erroneous bugs are A query JIT was first implemented by PostgreSQL in version 11, and it was made default in version 12. PuppetDB now disables the JIT for all of its queries because it currently makes some queries substantially more expensive.

PuppetDB 7.0.0

It was released on November 19, 2020.

Its bug fixes are mentioned below:

• In order to suppress occasional momentary connection problems, PuppetDB no longer internally retries requests. Instead, it gives an error code right away.
• PuppetDB won't keep a second open database connection while processing query requests. Previously, at the initial stage of the response, it would create and maintain an additional connection open.

It is no longer recommended to use PostgreSQL 9.6 or 10 with PuppetDB. Instead, use PostgreSQL 11 or higher.

Versioning policy

To help developers and users understand the guidelines we aim to adhere to internally, we will demonstrate how we version the PuppetDB software in this area of the blog. When it comes to PuppetDB, there are several distinct levels of versioning to take into account: PuppetDB application, HTML API, API Metrics, Instructions, and wire formats, Upgrades.

Normal version numbers MUST NOT have leading zeroes and have the format X.Y.Z, where X, Y, and Z are non-negative integers. The major version is designated as X, the minor version as Y, and the patch version as Z. 

HTTP API

There are four possible states for a versioned API: 

• Current
• Experimental/Future
• Deprecated
• Retired

Current 

If the modification is mostly judged backward compatible, the present "stable" or "current" API may be changed (so long as the consumer is less strict about new unexpected parameters). However, only in experimental API versions can changes that modify endpoints, fields, and query operators be made.

Experimental

Any "breaking" modifications that are not backward-compatible should be made to the experimental API. A few of the features in this API version also need to go through some user testing and experimentation before they can be incorporated into the current version.

In order to quickly improve this next API, the experimental API may be changed without prior warning.

Retired

APIs are no longer in use and have been withdrawn. Typically, a deprecated API will be implicitly discontinued at the following PuppetDB X release boundary. At this point, all functionality and documentation have been eliminated.

Known issues

• Requests for PuppetDB fact-contents take longer than normal: A change to the fact-contents query in PuppetDB 6.20.0 and 7.9.0 is aimed to decrease the number of reads Postgres needs and enhance performance for larger datasets. When PostgreSQL JIT compilation is enabled when using the changes, performance is negatively impacted. You should turn off JIT by setting jit = off in your PostgreSQL. conf if you have it enabled, either by setting it in PostgreSQL 11 or using the default settings in PostgreSQL 12+.
   
• An error is sent by PuppetDB from the status endpoint: When a user asks the /status/v1/services/puppetdb-status endpoint in PuppetDB 6.11.0, 6.11.1, or 6.11.2 and PuppetDB is unable to connect to the database, an exception is returned in the status response rather than the databases being reported as down.
   
• PuppetDB denies SSL connections from Puppet Server: Due to a limited selection of cipher suites, PuppetDB 6.6.0 and later can refuse Puppet Server SSL connections. The default encryption suites for PuppetDB will be changed to match those used by Puppet Server in a future release. The temporary fix is to manually set the cipher suites.
   
• The links between puppet resource types and other resources, known as "autorequirements," are ambiguous since we don't adequately model them in puppetDB. The issue is that the Puppet agent builds these connections as it reads the catalog; these dependencies are not recorded in the catalog. It will take a considerable overhaul of Puppet's foundation to incorporate these linkages into PuppetDB.

Frequently Asked Questions

What is a facter?

A library called facter tracks down and informs the Puppet Master of Facts that are pertinent to each Agent. The Manifests of the Puppet Master then contain the facts as variables.

What is a puppet catalog?

The Puppet Agent configures a node using a document called the Puppet Catalog. The Puppet Master provides the catalog for the agent to download. Each resource that has to be managed has a desired state that is described in the catalog.

What is a class in puppets?

A chunk of puppet code called a class is kept in modules for subsequent use. Puppet does not apply classes until you explicitly invoke them. Classes could be declared in the manifests and added to the catalog. For configuring large or medium-sized functional components, classes work well.

Conclusion

To conclude the blog, firstly we discussed the system requirements of puppetDB 7, making a contribution to puppetDB by making changes, testing, and submitting changes. Then we discussed many released notes of puppetDB and its versioning policy. In the end, we saw the known issues of the puppetDB.

For more content, Refer to our guided paths on Coding Ninjas Studio to upskill yourself.

Do upvote our blogs if you find them helpful and engaging!

Happy Learning!