| Hello Corey Benefrayim, I would like to make sure first that I understood the ticket's end goal correctly and kindly ask you to correct me if I got something wrong. Let's say that on a node, with the latest puppet installed, where the `ntp` package is already installed with version '1.5.2', we apply the following manifest: package { 'ntp': ensure => '1.5.3-1' } This action upgrades the `ntp` package from '1.5.2' to '1.5.3-1' and, from my current understanding, this happens as desired. The same would go for the scenario in which the `ntp` package was absent on the node when applying the manifest (which would result in a simple installation of '1.5.3-1' version). The issue appears only when our manifest ensures a lower version than what we already have installed. An example would be: package { 'ntp': ensure => '1.4' } This causes a downgrade of the `ntp` package from version '1.5.2' to '1.4' and that, from my current understanding, is not the desired behaviour. If everything said up to this point is true, then the ticket's feature request is basically finding a way to prevent any downgrade of packages managed with puppet to happen. A proposed solution would be to use a feature that our team implemented for Puppet 6.15 known as Version Ranges for package providers. This is currently available for the apt, yum, gem and pip package providers and adds the ability to ensure that a package's version satisfies a given range. For example: package { 'ntp': ensure => '> 1.4' } In the scenario where the `ntp` package is already installed with version '1.5.2', this manifest wouldn't do any changes when applied since the ensure property is already satisfied (version '1.5.2' on the box is newer than '1.4' given in the manifest). More information about the Version Ranges feature can be found in our Puppet Blog Post: https://puppet.com/blog/version-ranges-a-smarter-way-to-manage-packages-with-puppet/. If that alone wouldn't quite qualify as a solution then we could try implementing one of the improvement ideas we had for this feature. This implies ensuring the latest available version that satisfies a given range. Let's take the same manifest as above for example: package { 'ntp': ensure => '> 1.4' } Currently this will make changes at most one time, when the range is not satisfied. Once it is, no matter how many versions of the 'ntp' package will be released or how many times the manifest will be applied, there won't be any more changes. Our idea mentioned above would bring a configurable boolean parameter or some other mechanism (needs to be discussed and decided with the team) which would allow changes each time there is a version newer than '1.4' when activated in the manifest. This could also work for when you want to always be up to date but at the same time avoid a major release (through something like '< 2') when it appears so that any unwanted breaking changes are avoided. Again, please let us know if my understanding of the issue is correct and tell us if any of the above proposals would fit as a solution so that we know how to move forward with this ticket. |
