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 On Fri, Nov 29, 2013 at 12:49 PM, Gavin Williams <[email protected]> wrote: > 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 > > > On Friday, 29 November 2013 11:35:46 UTC, Kristof Willaert wrote: > >> 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 >> >> >> On Fri, Nov 29, 2013 at 12:10 PM, Gavin Williams <[email protected]>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/d1b8cc773024da0184 >>>> 4e4145ca5568ac6ee4ae0d >>>> [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. >>> >> >> -- > 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/b96c2083-a79f-4b47-936a-af1b126e7ef3%40googlegroups.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- 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/CACY92yOdU_%3DHJe-3peU0Swrx0hJ8yAxYLMUQ9UKHfNC7jzyuvg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
