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/ On Monday, 25 November 2013 14:29:36 UTC, Gavin Williams wrote: > > 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 > -- 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 [email protected]. 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.
