Ship latest concurrent-ruby with runtime projects

[donoghuc]

Use Case

The latest concurrent ruby gem contains performance improvments and bug fixes desirable for projects consuming runtime builds. Currently we are shipping 1.1.9 and 1.1.10. Projects that consume the runtime should be updated to support the latest and we should ship the latest concurrent ruby gem.

Describe the Solution You Would Like

Ship the latest concurrent-ruby gem with runtime projects.

Describe Alternatives You've Considered

If needed it is acceptable to pin back to older versions if there is a valid reason and a path forward for getting on the latest release.

Additional Context

At the very least we will need to update bolt's gemspec before we can merge the update in bolt's runtime. https://github.com/puppetlabs/bolt/blob/4db889af226d4308e137d34d6846c6d5a7bdfa79/bolt.gemspec#L49 IIRC that pin was due to an issue that has since been fixed in puppet and can safely be unrestricted now.

[donoghuc]

puppetlabs/bolt#3253

[github-actions]

Migrated issue to PA-5960

[justinstoller]

I assume this is the best spot to discuss details regarding this bump?

We should note that Puppet Server vendors concurrent-ruby and that needs to be bumped to either 1.1.10 or 1.2.2. Strictly speaking I don't think the platform needs to bump its vesion, but it would be ideal to keep Puppet Server and the platform in sync.

Updating the version of concurrent-ruby we ship to 1.2.0 or above will break many module author pins. This probably isn't too onerous because they had pinned concurrent-ruby as a workaround, but it does go against how we try to mange Open Source projects (not breaking dependencies in minor releases). Note, the version of concurrent-ruby we're updating to is not a new major version, so in theory it should be fine, it's our own usage of an apparently private class that is the issue.

If we can update concurrent-ruby to 1.1.10 it most likely will not break module authors. There is some concern that updating to anything less than 1.2.0 won't fully resolve the issue but we don't have evidence yet of that.

We need to decide: Do we update to latest concurrent-ruby (1.2.2), or do we update to latest in the 1.1.z line (1.1.10)? Do we choose one in main and another in 7.x? Do we only update Puppet Server and leave the platform wherever it is?

[justinstoller]

To publicly summarize an internal conversation:

• There's little appetite for trying limit the upgrade to anything less than latest of concurrent-ruby. And latest (1.2.2) seems stable.
• We want to keep the platform, all the projects built of it (bolt, pdk, etc), and Puppet Server on the same version of concurrent-ruby.
• This will break module dev workflows that resolve the Puppet gem and have already pinned concurrent-ruby to a version < 1.2.0. However, by putting this in both 7.x and 8.x users will be able to simply remove their pins of concurrent-ruby and not have to twizzle dependencies when running against latest of 7.x and 8.x. Also, the pin was a previous workaround to us not supporting the latest y release of concurrent-ruby. We see this more as being able to remove a workaround rather than introducing a breaking change.
• Internally we support several modules (puppet_agent module, cem modules, support dashboard, etc) that have these pins and we need to ticket and work with those teams affected to ensure they are not fire fighting when we do a release after the holidays.
• We should also speak to Vox Pupuli and potentially put out a notice on Puppet Users regarding this change.

[donoghuc]

This will break module dev workflows that resolve the Puppet gem and have already pinned concurrent-ruby to a version < 1.2.0. However, by putting this in both 7.x and 8.x users will be able to simply remove their pins of concurrent-ruby and not have to twizzle dependencies when running against latest of 7.x and 8.x. Also, the pin was a previous workaround to us not supporting the latest y release of concurrent-ruby. We see this more as being able to remove a workaround rather than introducing a breaking change.

I do want to note that we are not planning on changing the current gemspec for puppet 7 or 8. The only update we are making is shipping concurrent-ruby 1.2.2 in the packages we ship. Consumers of the puppet gem who are managing their own gem environments (and not using our packages) will not be impacted.

[joshcooper]

Fixed in #778 and #780