[puppet] Artificially inflated dependencies in metadata.json of all modules

Alex Schultz aschultz at redhat.com
Thu Mar 25 16:39:36 UTC 2021

On Thu, Mar 25, 2021 at 10:30 AM Thomas Goirand <zigo at debian.org> wrote:

> Hi,
> Each time there's a new release, all of the modules are getting a new
> set of lower bounds for:
> - openstack/keystone
> - openstack/openstacklib
> - openstack/oslo
> I just did a quick check and this really doesn't make sense. For
> example, for going from 18.2.0 to 18.3.0, there's no breakage of the API
> that would require a bump of version in all modules.
These are milestone releases and not tracked independently across all the
modules. I believe you are basically asking for the modules to go
independent and not have milestone releases.  While technically the version
interactions you are describing may be true for the most part in that it
isn't necessary, we assume the deployment as a whole in case something
lands that actually warrants this.  The reality is this only affects master
and you likely want to not track the latest versions until GA.

> So, could we please stop this non-sense and restore some kind of sanity
> in our dependency management ? FYI, I'm expressing these in the packaged
> version of the puppet modules, and it increase complexity for no reasons.
It feels like the ask is for more manual version management on the Puppet
OpenStack team (because we have to manually manage metadata.json before
releasing), rather than just automating version updates for your
packaging.  This existing release model has been in place for at least 5
years now if not longer so reworking the tooling/process to understand your
requirement seems a bit much given the lack of contributors.  If you feel
that you could get away with requiring >= 18 rather than a minor version,
perhaps you could add that logic in your packaging tooling instead of
asking us to stop releasing versions.

> A lower bound of a dependency should be increased *only* when really
> mandatory (ie: a backward compatibility breakage, a change in the API,
> etc.).
> Your thoughts?
> Cheers,
> Thomas Goirand (zigo)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210325/aedba730/attachment.html>

More information about the openstack-discuss mailing list