Any changes you make to the .repo files need to also trigger yum to clear out its local cache on your node. I don't know of a better way to trigger yum to clear out its cache, except for an execute resource that runs "yum clean all" whose default action is set to :nothing. Obviously, your template resources that create the .repo files, should notify that execute resource that runs "yum clean all".execute "yum_clean_all" docommand "yum clean all"action :nothingendtemplate "/etc/yum.repos.d/blah.repo" donotifies :run, "execute[yum clean all]"endObviously, these are very simple examples, but you get the picture.--DangOn 11/20/12 3:28 PM, "Eric G. Wolfe" < " target="_blank"> > wrote:It appears that behavior still is there. I don't quite understand the reasoning for that either. Surely, if you wanted to manage a repo file with a LWRP, wouldn't you want it to wipe out the file, and place the correct contents in there via template?
That is, if its managed via a template resource... Then, one would expect the template resource to do the right thing and re-write it, or check that the file is correct and then move on. If I needed to change the baseurl, I want the template resource to correct that url on every node, not skip over it if the file exists. Having to wipe out the file on each node, just seems wrong.Eric G. Wolfe Senior Linux Administrator, IT Infrastructure Systems -------------------------------------- Marshall University Computing Services Drinko Library 428-K One John Marshall Dr. Huntington, WV 25755 Phone: 304.942.3970 Email: " target="_blank"> You will be recognized and honored as a community leader.On 11/20/2012 06:13 PM, steve . wrote:Internally, we've gone as far as writing an ohai plugin that determines whether or not we're in a restricted data center environment before overriding yum repository sources and enabling/disabling repos.On a related note, I can't remember whether or not the yum_repo LWRP parses existing files for options in its load_current_resource() or just checks to see whether or not the file exists ... I just remember that when I change a Yum mirror I find that the mirrors don't get updated on my nodes until I nuke the repo file from /etc/yum.repos.d. But this is with an old fork... is that behavior still around?On Sat, Nov 17, 2012 at 9:11 AM, Joshua Buysse < " target="_blank"> > wrote:In that case, I'd fork the yum cookbook locally and override the epel recipe to do what I want with a local repo. For a cookbook, activating epel is the best general solution - if you're one of the small percentage that won't work for, it's easy enough to replace without problem as long as the cookbook uses yum::epel.
I would do the same thing for anything involving rpmforge, for example. I have a few packages that I rebuilt/resigned locally, but I haven't run in to that with a cookbook yet.
On Nov 17, 2012, at 9:11, Jeffrey Hulten < " target="_blank"> > wrote:
> Often I need things from EPEL but I also tend to create my own YUM mirror so I know what versions I am getting if I bring up a new box. In this case adding a repo would circumvent my controls.
> --
> Jeffrey Hulten
> Principal Consultant at Automated Labs, LLC
> " target="_blank"> 206-853-5216
> Skype: jeffhulten
>
> On Nov 16, 2012, at 9:56 PM, Tim Smith wrote:
>
>> Most everything we try to do requires EPEL so we have it enabled on
>> anything in Redhat-land.
>>
>> Tim Smith
>> Operations Engineer, SaaS Operations
>> M: +1 707.738.8132
>> TW: @tas50
>> webtrends <http://www.webtrends.com/>
>> Real-Time Relevance. Remarkable ROI.™
>> London | Portland | San Francisco | Melbourne | Tokyo
>>
>>
>>
>>
>>
>>
>> On 11/16/12 1:51 PM, "Eric G. Wolfe" < " target="_blank"> > wrote:
>>
>>> I can't speak for everyone on RHEL/CentOS, but I think there is at least
>>> one-off package from EPEL on every one of our systems. When writing a
>>> community cookbook, I never assume the end user has EPEL enabled, it
>>> does need to be coded into the recipe (or at least included via
>>> yum::epel). When I opened COOK-1772, the goal was to make that a
>>> uniform pattern which makes use of the yum::repository LWRP.
>>>
>>> Unfortunately I think there are still multiple issues with the yum
>>> cookbook on Amazon Linux, thanks to their platform_version differences.
>>> This isn't directly related to your question, but shouldn't EL family
>>> platforms return a consistent version number (OHAI-321)?
>>>
>>> Eric G. Wolfe
>>> Senior Linux Administrator,
>>> IT Infrastructure Systems
>>> --------------------------------------
>>> Marshall University Computing Services
>>> Drinko Library 428-K
>>> One John Marshall Dr.
>>> Huntington, WV 25755
>>> Phone: 304.942.3970
>>> Email: " target="_blank">
>>>
>>> You will be recognized and honored as a community leader.
>>>
>>> On 11/16/2012 04:29 PM, Bryan McLellan wrote:
>>>> Would you be surprised if you ran a community cookbook for a piece of
>>>> software and it configured EPEL to do so?
>>>>
>>>> It seems like getting most things done requires it, but we haven't made
>>>> a
>>>> global pattern yet to override the use of EPEL yet.
>>>>
>>>> If everyone just uses EPEL, then it is a moot point.
>>>>
>>>> ---
>>>> Bryan McLellan | opscode | technical program manager, open source
>>>> (c) 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org
>>>>
>>>>
>>>
>>
>
Archive powered by MHonArc 2.6.16.