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 On Friday, 29 November 2013 11:10:02 UTC, Gavin Williams wrote: > > 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/5d7775f0-5905-4baa-b47d-681e2b4670b7%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
