Jira (PUP-1519) Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number

3 views
Skip to first unread message

Elizabeth Wittig (JIRA)

unread,
Feb 11, 2016, 7:11:07 PM2/11/16
to puppe...@googlegroups.com
Elizabeth Wittig updated an issue
 
Puppet / New Feature PUP-1519
Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number
Change By: Elizabeth Wittig
CS Priority: Needs Priority
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)
Atlassian logo

Reid Vandewiele (JIRA)

unread,
Apr 7, 2016, 5:11:55 PM4/7/16
to puppe...@googlegroups.com
Reid Vandewiele commented on New Feature PUP-1519
 
Re: Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number

Copying the suggestion originally made in the Redmine issue. Implement a type feature called `minimum_versionable`.

feature :minimum_versionable, "The provider is capable of selectively
        upgrading to the latest version of a package if and only if the
        installed version is less than a provided minimum version. Using a
        minimum version of 1.5-2 as an example, this feature is used by
        specifing `>= 1.5-2` as the desired value for the package."

An example implementation was also filed at that time (this was years ago) and can be found here.

This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Atlassian logo

Elizabeth Plumb (JIRA)

unread,
Apr 7, 2016, 5:51:04 PM4/7/16
to puppe...@googlegroups.com

Henrik Lindberg (JIRA)

unread,
May 12, 2016, 7:45:04 PM5/12/16
to puppe...@googlegroups.com
Henrik Lindberg commented on New Feature PUP-1519
 
Re: Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number

We have just added two new types - SemVer and SemVerRange to the puppet type system. (We already had a good semver gem, but the packaging was a bit mixed up with one internal puppet version, and one vendored gem version). From Puppet 4.5.0 the latest version of the gem is included in the agent package and the two older implementations will be phased out.

The question in this ticket is if the min/max range (or set of ranges/constraints) should be expressed in one format across all packages (if so, SemVer is a natural choice), and that it after that is up to a provider to apply (and possibly transform that information) into matches against the particular package manager, or if the values given by the user is specific to that package manager's way of handling versions. Errors can be caught earlier if SemVer is used as input as that makes validation at compile time possible. Most package manager are close to Semver, but not all, and some packages may use version features that differ - so there would be corner cases if SemVer was used.

Henrik Lindberg (JIRA)

unread,
Jun 2, 2016, 7:19:05 PM6/2/16
to puppe...@googlegroups.com

Eric Sorenson (JIRA)

unread,
Jan 30, 2017, 7:23:05 PM1/30/17
to puppe...@googlegroups.com
Eric Sorenson updated an issue
Change By: Eric Sorenson
Team: Agent & Platform
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Atlassian logo

Eric Sorenson (JIRA)

unread,
Jan 30, 2017, 7:23:07 PM1/30/17
to puppe...@googlegroups.com

Eric Sorenson (JIRA)

unread,
Jan 30, 2017, 7:24:19 PM1/30/17
to puppe...@googlegroups.com

Eric Sorenson (JIRA)

unread,
Jan 30, 2017, 7:24:26 PM1/30/17
to puppe...@googlegroups.com
Eric Sorenson commented on New Feature PUP-1519
 
Re: Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number

This is in the top 5 most watched tickets and seems related to the other package improvements.

Geoff Nichols (JIRA)

unread,
Feb 1, 2017, 1:53:19 PM2/1/17
to puppe...@googlegroups.com
Geoff Nichols updated an issue
 
Puppet / Epic PUP-1519
Change By: Geoff Nichols
Scrum Team: Client Platform
Team: Agent & Platform
Team/s: Agent & Platform
Epic Status: To Do
Epic Name: Package resource should allow version constraint
Workflow: Scrum Team Engineering Epic  Workflow
Issue Type: New Feature Epic

Geoff Nichols (JIRA)

unread,
Apr 11, 2017, 11:45:04 PM4/11/17
to puppe...@googlegroups.com

Geoff Nichols (JIRA)

unread,
Apr 12, 2017, 12:46:09 PM4/12/17
to puppe...@googlegroups.com

John Duarte (JIRA)

unread,
May 15, 2017, 4:41:05 PM5/15/17
to puppe...@googlegroups.com

John Duarte (JIRA)

unread,
May 15, 2017, 4:41:06 PM5/15/17
to puppe...@googlegroups.com

Moses Mendoza (JIRA)

unread,
May 18, 2017, 1:49:41 PM5/18/17
to puppe...@googlegroups.com

Josh Cooper (JIRA)

unread,
May 26, 2017, 3:12:05 AM5/26/17
to puppe...@googlegroups.com

Josh Cooper (JIRA)

unread,
May 26, 2017, 3:12:07 AM5/26/17
to puppe...@googlegroups.com

Geoff Nichols (JIRA)

unread,
Jul 22, 2017, 1:52:06 AM7/22/17
to puppe...@googlegroups.com

Brad Beyenhof (JIRA)

unread,
Jul 22, 2017, 12:18:04 PM7/22/17
to puppe...@googlegroups.com
Brad Beyenhof commented on Epic PUP-1519
 
Re: Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number

Note that the proposed behavior seems more like "greater than or equal to," and the more natural syntax for that would be:

    package { 'foo': ensure=>'>=1.0' }

I can think of times where a simple "greater than" might also be desired, and also "less than or equal to," so perhaps all four operators should be supported.

Reid Vandewiele (JIRA)

unread,
Jul 24, 2017, 11:03:04 AM7/24/17
to puppe...@googlegroups.com

Hey Brad Beyenhof, can you share the use cases you're thinking of for "greater than", and "less than or equal to"? The important part I think is also what the desired behavior would be. So for each,

  1. Desired package version expression
  2. Expected action when out of sync

Example:

  1. Greater than or equal to, ">=". E.g. a vulnerability is known in a given version of openssl, 1.0.1f, and the desired assertion is that the version installed must be greater that or equal to 1.0.1f.
  2. Upgrade package to the latest available version

Having the use cases can help prioritize how much effort to put into each. It's worth pointing out that the semantics of what to do when a package is out of sync are probably the most complicated bit, and ">=" may be easier than others since the expected action when out of sync is already done - it's identical to the existing ensure=latest behavior.

In fact, because ">=" is easy and the others may be harder, it might be a good idea to just ticket them separately from the outset.

E Salberg (JIRA)

unread,
Jul 24, 2017, 11:27:04 AM7/24/17
to puppe...@googlegroups.com
E Salberg commented on Epic PUP-1519

We ran into this issue when we were upgrading Puppet agents - existing nodes were at 1.5.3, but new ones were at 1.7.1. We had to create a new classifier node group so that the upgraded nodes didn't throw "trying to downgrade but can't" errors.

Truthfully, this is a bigger issue for us on Windows, where the package resource doesn't handle "latest", than on RHEL, although we could have edge cases where this would be useful on RHEL as well.

Greater is most useful to us. For Less Than, I'm more likely to hardcode a specific version.

So for the bullets:
1. >= or > (either would be okay)
2. Upgrade package to latest would be fine for RHEL. Not sure what would happen for Windows - could there be an optional second variable that could specify what version to upgrade it to if it doesn't match the expression?

Brad Beyenhof (JIRA)

unread,
Jul 24, 2017, 1:38:13 PM7/24/17
to puppe...@googlegroups.com
Brad Beyenhof commented on Epic PUP-1519

Reid Vandewiele

If you know that a version of a package is bad and want to be higher:

    package { 'foo': ensure=>'>1.0' }

If the expression fails, install the latest available version.

If you've verified that a particular version is good and want to be at that or above, but another process (e.g. patching) can increase the version and you don't want Puppet to downgrade it with an explicit ensure=>$VERSION:

    package { 'foo': ensure=>'>=1.0' }

If the expression fails, install the latest available version. (This is what I want more anything else. We don't want Puppet downgrading packages, or having to continually update our package definitions whenever patching releases a new package to the internal repos.)

If you have a maximum version you'd like installed, and have verified anything higher will cause problems:

    package { 'foo': ensure=>'<=1.0' }

If the expression fails, downgrade the package to 1.0 (or install 1.0 if it's not installed yet).

If you know there's a particular version that has problems and you'd like to make sure Puppet does not upgrade to that version:

    package { 'foo': ensure=>'<1.0' }

If the expression fails, install the highest version available that's below 1.0. I'm not sure if this has an actual valid use case, but it might be good to have all possible comparison operators working. I don't think I would use it (verifying a "highest known good" seems more concrete than "upgrade, but not to this one"), but others might find it helpful.

If these four are all in operation, then you can easily define a range of acceptable versions:

    package { 'foo': ensure=>'>1.0' }
    package { 'foo': ensure=>'<=1.7' }

The package version must be greater than 1.0 but no greater than 1.7. In this case, Puppet should install version 1.7 if the package is not installed or currently below 1.0, but leave the current installation alone if both conditions are already met. "Latest available" in greater-than will be overridden by the assertion that the installed package cannot be greater than 1.7.

Henrik Lindberg (JIRA)

unread,
Dec 6, 2018, 5:12:06 AM12/6/18
to puppe...@googlegroups.com

As noted earlier, we have Semver and SemverRange data types and since Puppet 6.0.0 rich-data can be sent in the catalog. This makes it possible to use those types of values to construct advanced matching for the ensure value. (The type/provider can then interpret that). While versions are specified in different ways in different packages, it should be possible to interpret a semver version range (within the limits of what a particular provider can handle naturally).

This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

Josh Cooper (JIRA)

unread,
Apr 17, 2019, 5:55:06 PM4/17/19
to puppe...@googlegroups.com

Josh Cooper (JIRA)

unread,
Apr 19, 2019, 12:23:08 PM4/19/19
to puppe...@googlegroups.com

Kevin Reeuwijk (JIRA)

unread,
Jan 8, 2020, 4:46:05 AM1/8/20
to puppe...@googlegroups.com

Mihai Buzgau (JIRA)

unread,
Feb 5, 2020, 4:42:06 AM2/5/20
to puppe...@googlegroups.com

Mihai Buzgau (JIRA)

unread,
Feb 5, 2020, 4:46:06 AM2/5/20
to puppe...@googlegroups.com

Mihai Buzgau (JIRA)

unread,
Feb 5, 2020, 6:09:06 AM2/5/20
to puppe...@googlegroups.com

Kevin Reeuwijk (JIRA)

unread,
Feb 5, 2020, 7:38:06 AM2/5/20
to puppe...@googlegroups.com
 
Re: Package resource should allow ensure=>">1.0" or ensure=>"<0.10" as well as 'latest', 'installed' and specific version number

As the PR was abandoned, I built a new module for this functionality here: https://github.com/puppetlabs/puppetlabs-minimum_version

It provides a minimum_version() function (I renamed it) that can be added to PE by simply adding to module to the Puppetfile. This way it allows people to opt-in and won't break any existing functionality.

The syntax is:

minimum_version(String <package name>, String <minimum version>, Optional[String] <version_to_install_if_not_minimum>, Optional[String] <package provider>)

It is meant to be used in the ensure attribute of a package resource, like so:

package { 'python':
  ensure => minimum_version('python', '2.7.5-77.el7_6')
}

To install the latest available version when the minimum version is not present:

package { 'python':
  ensure => minimum_version('python', '2.7.5-77.el7_6', 'latest')
}

To install the latest available version of a gem when the minimum version is not present:

package { 'openssl':
  ensure   => minimum_version('python', '2.1.2', 'latest', 'gem')
  provider => gem
}

Kevin Reeuwijk (JIRA)

unread,
Feb 10, 2020, 10:32:05 AM2/10/20
to puppe...@googlegroups.com

Austin Boyd (JIRA)

unread,
Feb 19, 2020, 5:32:15 PM2/19/20
to puppe...@googlegroups.com

Austin Boyd (JIRA)

unread,
Feb 19, 2020, 5:32:16 PM2/19/20
to puppe...@googlegroups.com

Nick Walker (Jira)

unread,
May 12, 2020, 10:34:03 AM5/12/20
to puppe...@googlegroups.com
Nick Walker updated an issue
Change By: Nick Walker
Fix Version/s: PUP 6.16.0
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Atlassian logo

Mihai Buzgau (Jira)

unread,
May 26, 2020, 5:32:04 AM5/26/20
to puppe...@googlegroups.com

Gheorghe Popescu (Jira)

unread,
May 27, 2020, 7:00:05 AM5/27/20
to puppe...@googlegroups.com

Bogdan Irimie (Jira)

unread,
Nov 5, 2020, 3:51:04 AM11/5/20
to puppe...@googlegroups.com

Bogdan Irimie (Jira)

unread,
Nov 5, 2020, 3:52:06 AM11/5/20
to puppe...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages