[puppet][tc] Future of the project
I had similar discussions earlier in #puppet-openstack several times, but I think it's time to start more formal discussions. As some of you may know, Puppet OpenStack project has been facing several challenges for a few years due to the changes made in the external but related communities, and very honestly speaking, the project is at risk. IMO we have two major challenges now. - RDO officially announced that they discontinue RPM builds and focus on new container-base delivery, based on source-to-build. https://lists.rdoproject.org/archives/list/users@lists.rdoproject.org/thread... Because the primary (and only) architecture we currently support is installation from packages, this means CentOS Stream may no longer be in our support scope. CentOS Stream + RDO has been the primary (and only voting) test architecture because it provides the trunk packages which allow us to test the latest code in development. We could technically switch our primary test architecture to the other platforms like Ubuntu or Debian but this means we can't release our modules in coordinated release timings (because we can implement and test the changes for a new version only after the version is released by these distributions) As we've seen some drastic changes triggered by some initiatives (like eventlet removal) and expect more coming soon, this "lagging-behind" development models can cause several problems like [1]. [1] https://review.opendev.org/c/openstack/puppet-neutron/+/978000 - The upstream puppet has been "dead" after Perforce (who acquired puppetlabs) changed their strategies. OpenVox was created as a fork of puppet, but there are number of core modules such as puppetlabs-apache or puppetlabs-mysql which are not yet forked. I've asked possibility to fork and host these in OpenVox but it was not acceptable due to limited resources the OpenVox community and no real commitment (more specifically speaking, sponsorship) I can provide. There are some works done earlier to replace puppet by OpenVox but it is essentially blocked by the fixes needed in these "abandoned" puppetlabs modules. In addtion, we need to bump versions of our testing platform soon, and I expect these unmaintained modules cause new problems. As afar as I'm aware of, migration to CentOS 10 is completely blocked by "unmaintained puppetlabs-mysql[2], and I expect more for migration to Ubuntu 26.04 or Debian 14 we need in upcoming cycles. [2] https://github.com/puppetlabs/puppetlabs-mysql/issues/1676 So... The situation is getting out of my control and I'd admit that I may soon terminate the project in case the situation is not improved, given my work in the OpenStack community has been all voluntary-based these days. I intend to continue my PTL role of this project for next cycle, so that I can help anyone who would be interested in sustaining the project, but I hope that we get some conclusion and agreement about the future project direction and maintenance during this cycle. Please reply to this in thread or reach me directly (in email or irc) if you are interested in further discussions. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
Hi puppeteers, First thanks to the work done by Takashi and others on the puppet modules, I really appreciate ! I just want to make you aware that the problems around the perforce "maintained" modules is also discussed in the openvox community. OpenVox as Takashi already said is the actively puppet fork maintained by Voxpupuli. Voxpupuli already maintaince a big number of opensource puppet modules, which also depend on the perforce "maintained" modules. So there is a high demand of the whole community to fork especially the modules Takashi mentioned (mysql, apache etc). I expect these to be taken by Voxpupuli. Currently there is a discussion about the License to choose for such forks [1]. So I expect the second 'problem' about the depend modules will be solvable by the communities. Benedikt [1] https://github.com/voxpupuli/community-triage/issues/92 On 04.03.26 18:13, Takashi Kajinami wrote:
- The upstream puppet has been "dead" after Perforce (who acquired puppetlabs) changed their strategies. OpenVox was created as a fork of puppet, but there are number of core modules such as puppetlabs-apache or puppetlabs-mysql which are not yet forked. I've asked possibility to fork and host these in OpenVox but it was not acceptable due to limited resources the OpenVox community and no real commitment (more specifically speaking, sponsorship) I can provide. There are some works done earlier to replace puppet by OpenVox but it is essentially blocked by the fixes needed in these "abandoned" puppetlabs modules. In addtion, we need to bump versions of our testing platform soon, and I expect these unmaintained modules cause new problems. As afar as I'm aware of, migration to CentOS 10 is completely blocked by "unmaintained puppetlabs-mysql[2], and I expect more for migration to Ubuntu 26.04 or Debian 14 we need in upcoming cycles. [2] https://github.com/puppetlabs/puppetlabs-mysql/issues/1676
So... The situation is getting out of my control and I'd admit that I may soon terminate the project in case the situation is not improved, given my work in the OpenStack community has been all voluntary-based these days.
I intend to continue my PTL role of this project for next cycle, so that I can help anyone who would be interested in sustaining the project, but I hope that we get some conclusion and agreement about the future project direction and maintenance during this cycle.
Please reply to this in thread or reach me directly (in email or irc) if you are interested in further discussions.
Thank you, Takashi
Hi Benedikt, Thanks for sharing that information. I wasn't aware of it and it sounds like a very nice news. I'll check the discussion and will try to be involved. Thank you, Takashi On 3/5/26 3:24 AM, Benedikt Trefzer wrote:
Hi puppeteers,
First thanks to the work done by Takashi and others on the puppet modules, I really appreciate !
I just want to make you aware that the problems around the perforce "maintained" modules is also discussed in the openvox community. OpenVox as Takashi already said is the actively puppet fork maintained by Voxpupuli. Voxpupuli already maintaince a big number of opensource puppet modules, which also depend on the perforce "maintained" modules. So there is a high demand of the whole community to fork especially the modules Takashi mentioned (mysql, apache etc). I expect these to be taken by Voxpupuli. Currently there is a discussion about the License to choose for such forks [1].
So I expect the second 'problem' about the depend modules will be solvable by the communities.
Benedikt
[1] https://github.com/voxpupuli/community-triage/issues/92
On 04.03.26 18:13, Takashi Kajinami wrote:
- The upstream puppet has been "dead" after Perforce (who acquired puppetlabs) changed their strategies. OpenVox was created as a fork of puppet, but there are number of core modules such as puppetlabs-apache or puppetlabs-mysql which are not yet forked. I've asked possibility to fork and host these in OpenVox but it was not acceptable due to limited resources the OpenVox community and no real commitment (more specifically speaking, sponsorship) I can provide. There are some works done earlier to replace puppet by OpenVox but it is essentially blocked by the fixes needed in these "abandoned" puppetlabs modules. In addtion, we need to bump versions of our testing platform soon, and I expect these unmaintained modules cause new problems. As afar as I'm aware of, migration to CentOS 10 is completely blocked by "unmaintained puppetlabs-mysql[2], and I expect more for migration to Ubuntu 26.04 or Debian 14 we need in upcoming cycles. [2] https://github.com/puppetlabs/puppetlabs-mysql/issues/1676
So... The situation is getting out of my control and I'd admit that I may soon terminate the project in case the situation is not improved, given my work in the OpenStack community has been all voluntary-based these days.
I intend to continue my PTL role of this project for next cycle, so that I can help anyone who would be interested in sustaining the project, but I hope that we get some conclusion and agreement about the future project direction and maintenance during this cycle.
Please reply to this in thread or reach me directly (in email or irc) if you are interested in further discussions.
Thank you, Takashi
Hi Takashi, On 3/4/26 6:13 PM, Takashi Kajinami wrote:
We could technically switch our primary test architecture to the other platforms like Ubuntu or Debian but this means we can't release our modules in coordinated release timings (because we can implement and test the changes for a new version only after the version is released by these distributions)
Well, not sure what the problem is from the Debian side: over the last few years, I've been able to release the Debian packages the day (or a few days after) of the upstream release.
As we've seen some drastic changes triggered by some initiatives (like eventlet removal) and expect more coming soon, this "lagging-behind" development models can cause several problems like [1]. [1] https://review.opendev.org/c/openstack/puppet-neutron/+/978000
This isn't new, is it?
- The upstream puppet has been "dead" after Perforce (who acquired puppetlabs) changed their strategies. OpenVox was created as a fork of puppet, but there are number of core modules such as puppetlabs-apache or puppetlabs-mysql which are not yet forked. I've asked possibility to fork and host these in OpenVox but it was not acceptable due to limited resources the OpenVox community and no real commitment (more specifically speaking, sponsorship) I can provide. There are some works done earlier to replace puppet by OpenVox but it is essentially blocked by the fixes needed in these "abandoned" puppetlabs modules. In addtion, we need to bump versions of our testing platform soon, and I expect these unmaintained modules cause new problems. As afar as I'm aware of, migration to CentOS 10 is completely blocked by "unmaintained puppetlabs-mysql[2], and I expect more for migration to Ubuntu 26.04 or Debian 14 we need in upcoming cycles. [2] https://github.com/puppetlabs/puppetlabs-mysql/issues/1676
I do not see the switch to openvox as problematic. Maybe because I've been using a packaged, and sometimes strongly patched, version of the puppet modules. Have you seen issues in the current versions of puppetlabs-apache or puppetlabs-mysql? If there was, I wouldn't be surprised to see forks happening.
So... The situation is getting out of my control and I'd admit that I may soon terminate the project in case the situation is not improved, given my work in the OpenStack community has been all voluntary-based these days.
This would be very disappointing. I very much regret that I wasn't able to invest more time helping you to support Debian better, especially when you've attempted to add it to the CI. But maybe we can retry? How much of puppet-openstack are you using in your work?
I intend to continue my PTL role of this project for next cycle, so that I can help anyone who would be interested in sustaining the project, but I hope that we get some conclusion and agreement about the future project direction and maintenance during this cycle.
Apart from you, Tobias and myself (less than you 2), who's contributing actively? I would be really sad to see all of this go... :/ Cheers, Thomas Goirand (zigo)
On 3/5/26 6:54 PM, Thomas Goirand wrote:
Hi Takashi,
On 3/4/26 6:13 PM, Takashi Kajinami wrote:
We could technically switch our primary test architecture to the other platforms like Ubuntu or Debian but this means we can't release our modules in coordinated release timings (because we can implement and test the changes for a new version only after the version is released by these distributions)
Well, not sure what the problem is from the Debian side: over the last few years, I've been able to release the Debian packages the day (or a few days after) of the upstream release.
The problem for me, who maintain consistency between these modules and the service components before a new version is actually packaged and released by distributions, is that I need un-released trunk version to test a new feature added in master. One good example is parameter renaming and we can't update our modules to use the new option until we get a new package supporting it. This hasn't caused problems very often because most of the available options are optional, but in case we get fundamental options (such as tenant_network_type -> project_network_type renaming) the eventual migration is blocked. We can't update or test our modules for N+1 release until N+1 release is actually shipped by distributions, which essentially cause a few months delay between OpenStack release and our module release.
As we've seen some drastic changes triggered by some initiatives (like eventlet removal) and expect more coming soon, this "lagging-behind" development models can cause several problems like [1]. [1] https://review.opendev.org/c/openstack/puppet-neutron/+/978000
This isn't new, is it?
It is. In the past several cycles we used RDO trunk packages to test unreleased code.
- The upstream puppet has been "dead" after Perforce (who acquired puppetlabs) changed their strategies. OpenVox was created as a fork of puppet, but there are number of core modules such as puppetlabs-apache or puppetlabs-mysql which are not yet forked. I've asked possibility to fork and host these in OpenVox but it was not acceptable due to limited resources the OpenVox community and no real commitment (more specifically speaking, sponsorship) I can provide. There are some works done earlier to replace puppet by OpenVox but it is essentially blocked by the fixes needed in these "abandoned" puppetlabs modules. In addtion, we need to bump versions of our testing platform soon, and I expect these unmaintained modules cause new problems. As afar as I'm aware of, migration to CentOS 10 is completely blocked by "unmaintained puppetlabs-mysql[2], and I expect more for migration to Ubuntu 26.04 or Debian 14 we need in upcoming cycles. [2] https://github.com/puppetlabs/puppetlabs-mysql/issues/1676
I do not see the switch to openvox as problematic. Maybe because I've been using a packaged, and sometimes strongly patched, version of the puppet modules. Have you seen issues in the current versions of puppetlabs-apache or puppetlabs-mysql? If there was, I wouldn't be surprised to see forks happening.
At this moment the main problem I noticed is not about replacing puppet by openvox. It's about replacing all our testing methods which currently heavily depends on puppetlab's things by openvox things. One example is beaker which we replaced by litmus some time ago, but we have to replace it back by beaker because litmus is under puppetlab's governance. https://github.com/puppetlabs/puppetlabs-mysql/pull/1687 is the one currently blocking my attempt to move our acceptance tests back from litmus to beaker. Also, there are number of logics dependent on distribution version (for example puppetlabs-mysql maintains the default mysql/mariadb version in each major release) we often have to update these modules to support new major operating system version. Yes, you can create a fork to mitigate the problems, but I don't think it's quite feasible and sustainable to maintain such fork just for our use case within OpenStack.
So... The situation is getting out of my control and I'd admit that I may soon terminate the project in case the situation is not improved, given my work in the OpenStack community has been all voluntary-based these days.> This would be very disappointing. I very much regret that I wasn't able to invest more time helping you to support Debian better, especially when you've attempted to add it to the CI. But maybe we can retry?
We could restore the work to add Debian-based integration tests, but the 2nd problem about unmaintained modules may likely affect it soon.
How much of puppet-openstack are you using in your work?
Unfortunately, none.
I intend to continue my PTL role of this project for next cycle, so that I can help anyone who would be interested in sustaining the project, but I hope that we get some conclusion and agreement about the future project direction and maintenance during this cycle.
Apart from you, Tobias and myself (less than you 2), who's contributing actively?
I've seen Benedikt and Francesco are also contributing the project for some time for some module updates. # I've been the only person taking care of the CI part for some time, though.
I would be really sad to see all of this go... :/
Cheers,
Thomas Goirand (zigo)
Hi, as other have said VoxPupuli is trying to adopt the Puppetlabs module as they're essential to VoxPupuli's own modules (for example puppet-openvoxdb dependencies are /all/ from Perforce) Regarding active contributions I'd like to be more involved, did MR in the past but had to pause due to other commitments (including involvement in VoxPupuli), now I'm "back to the cloud" :) For the distro problem, maybe Cloud SIGs of RHEL-based distributions (AlmaLinux, Rocky Linux etc) might be interested in switching to their own pipelines/build systems? Or there might be interested in providing trunk builds in Debian. Francesco -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email:francesco.dinucci@na.infn.it On 05/03/26 15:00, Takashi Kajinami wrote:
On 3/5/26 6:54 PM, Thomas Goirand wrote:
Hi Takashi,
On 3/4/26 6:13 PM, Takashi Kajinami wrote:
We could technically switch our primary test architecture to the other platforms like Ubuntu or Debian but this means we can't release our modules in coordinated release timings (because we can implement and test the changes for a new version only after the version is released by these distributions)
Well, not sure what the problem is from the Debian side: over the last few years, I've been able to release the Debian packages the day (or a few days after) of the upstream release.
The problem for me, who maintain consistency between these modules and the service components before a new version is actually packaged and released by distributions, is that I need un-released trunk version to test a new feature added in master. One good example is parameter renaming and we can't update our modules to use the new option until we get a new package supporting it. This hasn't caused problems very often because most of the available options are optional, but in case we get fundamental options (such as tenant_network_type -> project_network_type renaming) the eventual migration is blocked.
We can't update or test our modules for N+1 release until N+1 release is actually shipped by distributions, which essentially cause a few months delay between OpenStack release and our module release.
As we've seen some drastic changes triggered by some initiatives (like eventlet removal) and expect more coming soon, this "lagging-behind" development models can cause several problems like [1]. [1] https://review.opendev.org/c/openstack/puppet-neutron/+/978000
This isn't new, is it?
It is. In the past several cycles we used RDO trunk packages to test unreleased code.
- The upstream puppet has been "dead" after Perforce (who acquired puppetlabs) changed their strategies. OpenVox was created as a fork of puppet, but there are number of core modules such as puppetlabs-apache or puppetlabs-mysql which are not yet forked. I've asked possibility to fork and host these in OpenVox but it was not acceptable due to limited resources the OpenVox community and no real commitment (more specifically speaking, sponsorship) I can provide. There are some works done earlier to replace puppet by OpenVox but it is essentially blocked by the fixes needed in these "abandoned" puppetlabs modules. In addtion, we need to bump versions of our testing platform soon, and I expect these unmaintained modules cause new problems. As afar as I'm aware of, migration to CentOS 10 is completely blocked by "unmaintained puppetlabs-mysql[2], and I expect more for migration to Ubuntu 26.04 or Debian 14 we need in upcoming cycles. [2] https://github.com/puppetlabs/puppetlabs-mysql/issues/1676
I do not see the switch to openvox as problematic. Maybe because I've been using a packaged, and sometimes strongly patched, version of the puppet modules. Have you seen issues in the current versions of puppetlabs-apache or puppetlabs-mysql? If there was, I wouldn't be surprised to see forks happening.
At this moment the main problem I noticed is not about replacing puppet by openvox. It's about replacing all our testing methods which currently heavily depends on puppetlab's things by openvox things. One example is beaker which we replaced by litmus some time ago, but we have to replace it back by beaker because litmus is under puppetlab's governance. https://github.com/puppetlabs/puppetlabs-mysql/pull/1687 is the one currently blocking my attempt to move our acceptance tests back from litmus to beaker.
Also, there are number of logics dependent on distribution version (for example puppetlabs-mysql maintains the default mysql/mariadb version in each major release) we often have to update these modules to support new major operating system version.
Yes, you can create a fork to mitigate the problems, but I don't think it's quite feasible and sustainable to maintain such fork just for our use case within OpenStack.
So... The situation is getting out of my control and I'd admit that I may soon terminate the project in case the situation is not improved, given my work in the OpenStack community has been all voluntary-based these days.> This would be very disappointing. I very much regret that I wasn't able to invest more time helping you to support Debian better, especially when you've attempted to add it to the CI. But maybe we can retry?
We could restore the work to add Debian-based integration tests, but the 2nd problem about unmaintained modules may likely affect it soon.
How much of puppet-openstack are you using in your work?
Unfortunately, none.
I intend to continue my PTL role of this project for next cycle, so that I can help anyone who would be interested in sustaining the project, but I hope that we get some conclusion and agreement about the future project direction and maintenance during this cycle.
Apart from you, Tobias and myself (less than you 2), who's contributing actively?
I've seen Benedikt and Francesco are also contributing the project for some time for some module updates. # I've been the only person taking care of the CI part for some time, though.
I would be really sad to see all of this go... :/
Cheers,
Thomas Goirand (zigo)
participants (4)
-
Benedikt Trefzer
-
Francesco Di Nucci
-
Takashi Kajinami
-
Thomas Goirand