Development Compatibility in the Puppet Ecosystem

[davidsandilands]

Hello, we want to guarantee ongoing interoperability for modules and tools across Puppet and the open source community. What adjustments or investments should we make together in the ecosystem to ensure the long term interoperability and consistent support?

[kenyon]

Returning to a fully open source ecosystem would probably be the easiest and best thing to do.

[jstraw]

Barring @kenyon's obvious answer, ensure that the engineering teams directly talk to the openvox folks about what is going on without filtering by folks that don't understand the changes being made at a code level.

Ensure that the pieces of glue that actively have to be perfectly in sync are OSS (facter first among others)

[cvquesty]

Can't disagree here.

Here's what I fear. We in the community fix a long-standing or internal bug or even add a feature that Perforce have no interest in... suddenly the codebases diverge. Not too bad, but later the Forge modules start taking advantage of ${fix|feature} and now they're incompatible with Puppet Core.

This is the real issue that I haven't seen talked about openly as of yet.

[ripienaar]

This seems an inevitable outcome, we will have the language steering committee but I dont think we can assume both will implement its 1:1 and bug:bug.

With the hostile EULA situation, interoperability will suffer and I think in the long run Vox modules only supporting Vox is inevitable. We will have no way to actually verify the compatibility and Puppet Core is opaque to the community.

This is an avoidable situation but it's not up to the people on this thread.

[bastelfreak]

I will repeat what I'm saying since a few years:

• Make Vox Pupuli the upstream for puppet open source development
• That means that Perforce engineers develop first in the vox pupuli namespace (or now openvox)
• Drop the "puppet core" product
• transfer https://rubygems.org/gems/puppet to vox pupuli
• make PE a proper downstream product (and please consider replacing the poorly maintained PE console with foreman plugins), don't develop PE in parallel to your open source tools

I don't see how the tools maintained by Vox Pupuli will be compatible with "puppet core" nor PE, because we cannot test against them and I cannot imagine that you provide an acceptable EULA. The result is that all the tools like facterdb, rspec-puppet-facts, beaker, cannot depend on the puppet gem anymore. We will have to update them to use our openvox releases, and that would break all the tools owned by Perforce, like rspec-puppet.

[smortex]

💯 and same also apply to the facter gem obviously.

The upstream must be open/public — and will be, in the end, regardless of what Perforce does.

Let me explain again, using the Puppet repository as an example. The situation is the same for the other repositories Tim mentioned.

The old upstream, puppetlabs/puppet, hasn't been touched in months. PRs have been waiting to be merged for months, but new PRs are still being submitted to fix bugs and add features.

We've been told that some Puppet development happens in a private repo and that these changes will eventually be merged into the legacy puppetlabs/puppet repo. But in the meantime, the Vox community had no choice but to fork the repo in order to continue building packages that Perforce stopped providing. We had to fork because we needed to modify the code to build the packages. And in doing so, we made changes that resulted in new commits on the main branch.

So, the current situation involves three code repositories:

1. puppetlabs/puppet - the legacy upstream that's essentially dead ☠️;
2. ???/??? - the Perforce-flavored Puppet, based on puppetlabs/puppet, where development is expected to happen. There may be commits here, but we can only hope this work exists and isn't just speculation;
3. OpenVoxProject/puppet - the Vox-flavored Puppet, based on puppetlabs/puppet, with additional commits on top that are visible to anyone.

In a best-case scenario, everyone would stop using puppetlabs/puppet and switch to either the Perforce or the Vox package. Users would be able to send PRs to the Vox repo, or file tickets with support if they chose the wrong project where the code is hidden. 🤷

Unfortunately, Perforce wants to occasionally make its changes public, which means they want puppetlabs/puppet to be revived and updated with commits from ???/???. This will trick people into thinking that puppetlabs/puppet is not dead, and they will try to contribute to it — only to find that their changes won't be merged. This is because the upstream of puppetlabs/puppet is now ???/???, and it makes no sense to patch the now downstream repo.

As OpenVoxProject/puppet and ???/??? continue to diverge from puppetlabs/puppet, it will become harder for Vox to integrate changes from ???/??? into OpenVoxProject/puppet.

At some point, contributors will likely realize that sending PRs to puppetlabs/puppet is futile, they will not be able to contribute to ???/??? so they will begin submitting them to OpenVoxProject/puppet instead. This will increase the divergence between the two flavors of the project.

Eventually, integrating Perforce changes into the Vox-flavored repo will no longer be worth the effort. The situation will then reach a hard fork, where each project follows its own path without worrying about compatibility with the other.

At that point, all projects relying on Puppet will face a choice and no easy way to change their mind later: use the Perforce-flavored Puppet or the Vox-flavored Puppet. The choice will boil down to:

• The version backed by a company that has had hostile behavior, or the version backed by the community;
• The version you can download from a private repo after signing an EULA, or the version you can download freely from the internet;
• The version that requires a license, or the one with no prerequisites;
• The version that breaks when you have 26 nodes, or the one that crashes when you have too many nodes.

As a company that needs warranties and a third party to hold accountable in case of issues, I might have a choice.

But as a free software enthusiast, I see no choice here.

And as a developer in the Puppet ecosystem (e.g., a developer of a Puppet module) who needs their code to run in CI to ensure it works properly, I see no choice here either.

Once the hard fork happens, modules will need to specify whether they work with the Perforce-flavored Puppet or the Vox-flavored Puppet. Not being able to run CI on the former will likely lead to people not claiming support for the Perforce-flavored Puppet.

This outcome is inevitable unless there is a SINGLE upstream that both the Vox and Perforce packages use.

[cvquesty]

So well said.  Thank you.Sent from my iPhoneOn Feb 20, 2025, at 8:24 PM, Romain Tartière ***@***.***> wrote: 💯 and same also apply to the facter gem obviously. The upstream must be open/public — and will be, in the end, regardless of what Perforce does. Let me explain again, using the Puppet repository as an example. The situation is the same for the other repositories Tim mentioned. The old upstream, puppetlabs/puppet, hasn't been touched in months. PRs have been waiting to be merged for months, but new PRs are still being submitted to fix bugs and add features. We've been told that some Puppet development happens in a private repo and that these changes will eventually be merged into the legacy puppetlabs/puppet repo. But in the meantime, the Vox community had no choice but to fork the repo in order to continue building packages that Perforce stopped providing. We had to fork because we needed to modify the code to build the packages. And in doing so, we made changes that resulted in new commits on the main branch. So, the current situation involves three code repositories: puppetlabs/puppet - the legacy upstream that's essentially dead ☠️; ???/??? - the Perforce-flavored Puppet, based on puppetlabs/puppet, where development is expected to happen. There may be commits here, but we can only hope this work exists and isn't just speculation; OpenVoxProject/puppet - the Vox-flavored Puppet, based on puppetlabs/puppet, with additional commits on top that are visible to anyone. In a best-case scenario, everyone would stop using puppetlabs/puppet and switch to either the Perforce or the Vox package. Users would be able to send PRs to the Vox repo, or file tickets with support if they chose the wrong project where the code is hidden. 🤷 Unfortunately, Perforce wants to occasionally make its changes public, which means they want puppetlabs/puppet to be revived and updated with commits from ???/???. This will trick people into thinking that puppetlabs/puppet is not dead, and they will try to contribute to it — only to find that their changes won't be merged. This is because the upstream of puppetlabs/puppet is now ???/???, and it makes no sense to patch the now downstream repo. As OpenVoxProject/puppet and ???/??? continue to diverge from puppetlabs/puppet, it will become harder for Vox to integrate changes from ???/??? into OpenVoxProject/puppet. At some point, contributors will likely realize that sending PRs to puppetlabs/puppet is futile, they will not be able to contribute to ???/??? so they will begin submitting them to OpenVoxProject/puppet instead. This will increase the divergence between the two flavors of the project. Eventually, integrating Perforce changes into the Vox-flavored repo will no longer be worth the effort. The situation will then reach a hard fork, where each project follows its own path without worrying about compatibility with the other. At that point, all projects relying on Puppet will face a choice and no easy way to change their mind later: use the Perforce-flavored Puppet or the Vox-flavored Puppet. The choice will boil down to: The version backed by a company that has had hostile behavior, or the version backed by the community; The version you can download from a private repo after signing an EULA, or the version you can download freely from the internet; The version that requires a license, or the one with no prerequisites; The version that breaks when you have 26 nodes, or the one that crashes when you have too many nodes. As a company that needs warranties and a third party to hold accountable in case of issues, I might have a choice. But as a free software enthusiast, I see no choice here. And as a developer in the Puppet ecosystem (e.g., a developer of a Puppet module) who needs their code to run in CI to ensure it works properly, I see no choice here either. Once the hard fork happens, modules will need to specify whether they work with the Perforce-flavored Puppet or the Vox-flavored Puppet. Not being able to run CI on the former will likely lead to people not claiming support for the Perforce-flavored Puppet. This outcome is inevitable unless there is a SINGLE upstream that both the Vox and Perforce packages use. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>