I disagree that the package is misrepresenting anything. In the scenario above with a fix to Facter, the .z version of Facter would increment and the Puppet version would stay the same, because no changes. The .z version of the

puppet-agent

package would increment because there are net new bug fixes relative to the last

puppet-agent

package.

Upgrade successful! Thank you @CVQuesty and @Ben Roberts 😄 Just had to do

yum remove mongodb

and

yum remove mongodb-server

then change some ownership of the directories to match the user running it and it's back running. Thanks again!!

Seems to me like this is primarily a docs problem. If there was a clear distinction between

puppet-agent

the package and

puppet

the software in the main release notes landing page, no one would be having this argument.

The Puppet docs should be for the Puppet version (6.27.0), not the

puppet-agent

version (6.27.1). Puppet is used as a component in other AIOs, like Bolt and PE. But if a PE version shipped with Puppet 2.7.0 right now, there are no docs for it.

The

-1

doesn't have to be a prescription for every platform; my point was that packaging formats provide mechanisms to version package-only changes independently from the products. And even if they didn't, it would be simpler and clearer to take that concept and just add a digit to the package's version e.g.,

6.27.0.1

But that's not a problem either―if the X.Y.Z versions of Puppet and the

puppet-agent

AIO match. :P

But that's not a problem either―if the X.Y.Z versions of Puppet and the

puppet-agent

AIO match. 😛

But that's not a problem, either―if the X.Y.Z versions of Puppet and the

puppet-agent

AIO match. 😛

@Lindsey Smith has left the channel

This message was deleted.

It's hard to appreciate at first, because a surface view of the problem looks like a simple "black swan" AIO packaging hack. It's easy to forget there's an entire ecosystem that relies on the component version and not the package (and why).

This message was deleted.

message has been deleted

message has been deleted

This message was deleted.

so there is https://github.com/camptocamp/puppet-ghostbuster

@Lumiere In order to facilitate the transition, we are going to keep running the legacy networking infrastructure to connect to the Forge until 6/4/22. To use this network path, you can add a private DNS record pointing forge.puppet.com to 192.69.65.71

This message was deleted.

May I ask you about picking https://github.com/camptocamp/puppet-ghostbuster to vox populi as well? ;)

For this one, https://github.com/saimonn might be the best contact at Camptocamp

This message was deleted.

Is it possible to use facts for node classification or just hostname, regex (hostname), and

default

without an ENC?

Is it possible to use facts for node classification or just hostname, regex (hostname), and

default

without an ENC?

you could use hiera to do it, that's how our puppet 3 works

This message was deleted.

A common pattern is to put your fact-based logic in

node default {}

. See https://gist.github.com/natemccurdy/07e8f08f0b1811e8cbb8996bd08e5915 for some examples

Ah, I see. Thanks @natemccurdy.

Okay, technically this isn’t true. there’s the

node_name_fact

setting that could be used here…. but I’ve never found a valid reason to do this rather than custom logic in the

default

node definition: https://puppet.com/docs/puppet/7/configuration.html#node-name-fact

A couple jobs back we used Foreman for our ENC; I get the impression it has fallen out of favour lately. Is there a recommended ENC for Puppet OSS?

writing your own is pretty easy