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)