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]<javascript:>
> > 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] <javascript:>.
>> 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.
