Puppet and Yum versionlock...

[Gavin Williams]

Afternoon all

I've got a requirement whereby I need to be able to hold or pin specific versions of Yum packages, which ideally I want to be able to achieve using Puppet...

Looking at the latest package type documentation [1], I can see that some package providers support an ensure value of 'held'. Sounds perfect... However it looks like the Yum provider doesn't natively support this status :(
However a quick Google turned up the yum versionlock plugin[2], which seems to fit the bill, allowing specific packages to be locked to a specific version.

So that got me thinking - Why couldn't Puppet use yum-versionlock if it was installed, and therefore support the 'held' status for the yum package provider?

Digging through the Package type, I can see that the provider simply needs to support the 'holdable' feature.
Looking through the various package providers, it looks like dpkg and pkg are the only providers that currently support 'holdable'.

OK, that gives me an idea of where to start then... :)

After a bit of playing around this morning, I think I've got a partially working solution, as shown in this commit[3].

There are a couple of issues that I've come up against that I'm not sure of the best way to fix just yet...

1. The yum provider attempts to call self.unhold before any install actions. However self.unhold fails if there isn't an existing versionlock entry in place for the specified package name, as seen in [4]. So need some way of gracefully handling this failure and continuing...
   
2. `ensure => latest` doesn't want to pick up a later version of a locked package, even if explicitly asking Puppet to... Looking at the behaviour in the pkg/dpkg providers, they are also calling 'self.unhold' prior to attempting their install action. I'm not convinced if this is sensible behaviour or not... On the one hand, you could consider versionlock as a mechanism to guard against an inadvertent 'yum upgrade *' run, but allowing you to upgrade this specific package by setting `ensure => latest`. On the other, if you've versionlocked the version, should you explicitly unlock the package before attempting an update of said package?
   Anyhow, the wider issue here I believe is that the versionlock entry is preventing yumhelper.py from finding any available updates for said package... So need some way of telling yumhelper.py to ignore/disable any versionlock entries when compiling the 'latest_info'...
   

So, comments welcome on the code changes referenced in [3], and ideas on how to fix the 2 issues outlined above...

Cheers
Gav

[1] http://docs.puppetlabs.com/references/latest/type.html#package
[2] http://linux.die.net/man/1/yum-versionlock
[3] https://github.com/fatmcgav/puppet/commit/d1b8cc773024da01844e4145ca5568ac6ee4ae0d
[4] https://gist.github.com/fatmcgav/7641961

[Gavin Williams]

No-one with any comments?!?!

I've managed to spend a bit more time looking at the error handling issue outlined above, and have come up with a better solution, as shown in this commit[1].

Need to give some credit to Gary Larizza for the exception handling example in his latest blog post[2] on Puppet providers...

Still haven't managed to work out a way of getting 'ensure => latest' working against a 'held' package, however the more I think about it, the less I'm worried about that scenario... Currently, if you want to upgrade a held package, you need to specify the new version in 'ensure', which then un-holds the package and upgrades it... However you then need to set 'ensure => held' again to re-versionlock the package...

Comments welcome, but enjoy thanksgiving for those of you state side :)

Cheers
Gav

[1] https://github.com/fatmcgav/puppet/commit/117dc5a87c2771a0682b868582ad240739da8e35
[2] http://garylarizza.com/blog/2013/11/26/fun-with-providers-part-2/

[Kristof Willaert]

Hi Gavin,

we implemented the same functionality, but opted to use a type/provider combo for the locking functionality only[1][2]. This gave us the flexibility of

not having to maintain a patch to the yum provider.

It also allows us to pass a specific package version to a package resource and then lock it using the packagelock resource, something that
is not possible at the moment using only a package resource (as 'held' and a version are both values of the ensure property).

An example:

package { 'tomcat':

  ensure => '7.0.32-1'
}

packagelock { 'tomcat':

  ensure => present
}

We mainly use it to lock a few important packages down (JDK, tomcat, oracle-client, ...) and still be able to update the base OS

through "yum update" with controlled repositories.

We do have to remove the lock before being able to update the package, but it is considered an acceptable tradeoff here.

Feel free to comment, or use it for your own locking endeavours.

Regards,

k

[1] https://github.com/cegeka/puppet-stdlib/blob/master/lib/puppet/type/packagelock.rb
[2] https://github.com/cegeka/puppet-stdlib/blob/master/lib/puppet/provider/packagelock/yum.rb

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/c330dcc1-bcc1-49d0-8bf7-b2bf166e6b0a%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Gavin Williams]

Woops... Looks like I jumped the gun there and should've tested a bit more thoroughly...

Have tweaked the logic to use 'self.class.declared_feature?' rather than 'self.respond?', as I was always getting a 'false' response from 'self.respond?' even when :holdable was supported...

Latest commit is here[1]. You can get a better view of the total code changes here[2], and I've raised Feature #23316 on Redmine[3].

Cheers
Gav

[1]https://github.com/fatmcgav/puppet/commit/3a64eae111d5f152510ed8195072127924e68e60
[2]https://github.com/fatmcgav/puppet/compare/puppetlabs:master...master
[3]http://projects.puppetlabs.com/issues/23316

[Gavin Williams]

Kristof

Cheers for that... Didn't even think to look in stdlib...
Agreed that installing and locking at the same time would be beneficial, but can't see an easy way of implementing it with the yum package provider as it stands...

Will have a read through the stdlib code shortly...

Cheers
Gav

[Kristof Willaert]

Gavin,

be advised this is our stdlib module, not the one from Puppetlabs.

Although I am perfectly willing to submit the code to the Puppetlabs stdlib if anyone wants that.

Just yell.

Regards,

k

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/b96c2083-a79f-4b47-936a-af1b126e7ef3%40googlegroups.com.

[Felix Frank]

Well, I'm not sure that should be in stdlib, but it does sound like a
worthwhile Forge module indeed!

Thanks,
Felix