create_resources for /etc/yum.repos.d/ and getting along with purge

386 views
Skip to first unread message

Christopher Hyatt

unread,
Apr 16, 2015, 1:36:25 PM4/16/15
to puppet...@googlegroups.com
Repositories defined in yaml, yum module below. Understand some of my floundering is still in this module so things like ensure => "present" are not intended to be taken literally

What this really does is wipe out the entire /etc/yum.repos.d/ directory then recreates the repos from yaml, not ideal as it fills my dashboard with constant changes in my infrastructure.

Puppet 3.7.5-1 on Red Hat 6.5, 64bit


I would hope a work around would make puppet understand and catalogue properly every repository created with create_resources. The require was to stop Puppet from obliterating the /etc/yum.repos.d/ directory after creating the repositories.
I've searched plenty but perhaps I'm not using the right terminology. I can see several ways to handle it but none of them pretty, was hoping someone else saw this in the wild...

Regards, ~Chris

#init.pp
class yum {
  $yumconfig  
= hiera_array("yum::configuration")
  $repos      
= hiera("yum::repos")
  $repodefaults
= {
   
ensure  => "present",
   
require => File[ "/etc/yum.repos.d"],
 
}
  create_resources
(yumrepo, $repos, $repodefaults)
  file
{ "/etc/yum.repos.d":
   
ensure  => "directory",
    owner  
=> "root",
   
group   => "root",
    mode    
=> "0755",
    purge  
=> "true",
    recurse
=> "true",
 
}
  file
{ "/etc/yum.conf":
   
ensure  => "file",
    owner  
=> "root",
   
group   => "root",
    mode    
=> "0644",
    content
=> template("yum/yum_conf.erb"),
 
}
}


Christopher Hyatt

unread,
Apr 16, 2015, 2:27:55 PM4/16/15
to puppet...@googlegroups.com
I should also mention that I'm using the future parser.

jamese

unread,
Apr 17, 2015, 4:25:37 AM4/17/15
to puppet...@googlegroups.com
I've run into the same issue before.  The way I resolved it was to add a file resource for each yum repo, just ensuring it is present.  That way, the recursive purge on /etc/yum.repos.d/ doesn't nuke the repo files that puppet has created.  Arguably the yumrepo type should do that but it doesn't appear to - at least not when I wrote the module I'm using, which was maybe 2-3 years ago.

Gavin Williams

unread,
Apr 17, 2015, 4:41:03 AM4/17/15
to puppet...@googlegroups.com
Chris 

Take a look at the 'resources'[1] type, which you can use to purge unmanaged resources of a specific type. 

So rather than purging the entire directory using a file resource, you just purge the yum-repo files themselves... 

Something like:
resources {'yumrepo':
  purge
=> true
}
should do you... 

HTH
Gav

Gavin Williams

unread,
Apr 17, 2015, 4:41:37 AM4/17/15
to puppet...@googlegroups.com

Christopher Hyatt

unread,
Apr 17, 2015, 8:44:39 AM4/17/15
to puppet...@googlegroups.com
Thank you for the replies,

@Gavin, I attempted as you suggested but it still suffers from amnesia regarding the repos themselves. But it did get me looking at other work arounds and reading through to see if I can find a way for puppet with a meta parameter or such to recognize these files exist.

@jamese, that was what I was afraid of. We have a huge number of repositories due to the way we distribute software internally, I will keep that idea in my back pocket, but if I can avoid creating resources for each repo file, that would be much better.

Onto more reading, and messing around then. At least it works now. Albeit cluttering the dashboard. If I figure something out Ill be sure to post back.

Best regards, ~Chris

jamese

unread,
Apr 17, 2015, 9:27:37 AM4/17/15
to puppet...@googlegroups.com
I forgot to include this in my last post.  We created a defined type to wrap the yumrepo resource type.  The defined type then declares the yumrepo resource and the required file resource.
You could do the same, passing your defined type instead of yumrepo to the create_resources function.

The only annoyance of doing this is that there are a ton of parameters for the yumrepo that you need to replicate in the defined type.

However, since you are using the future parser, you could just write a .each loop and put the file and yumrepo resources in the loop, negating the need for create_resources or a defined type.  I'll probably do something similar to this when I get around to upgrading to Puppet 3.7/4.

jcbollinger

unread,
Apr 17, 2015, 9:35:27 AM4/17/15
to puppet...@googlegroups.com


On Friday, April 17, 2015 at 3:41:03 AM UTC-5, Gavin Williams wrote:
Chris 

Take a look at the 'resources'[1] type, which you can use to purge unmanaged resources of a specific type. 

So rather than purging the entire directory using a file resource, you just purge the yum-repo files themselves... 


Unfortunately, this only works for resource types that have an 'ensure' parameter, which Yumrepo does not.


John

Ken Barber

unread,
Apr 17, 2015, 9:43:27 AM4/17/15
to Puppet Users
> Unfortunately, this only works for resource types that have an 'ensure'
> parameter, which Yumrepo does not.

I was under the impression yumrepo was ensureable now:
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/yumrepo.rb#L16-L17
and https://docs.puppetlabs.com/references/latest/type.html#yumrepo

ken.

jcbollinger

unread,
Apr 17, 2015, 9:51:07 AM4/17/15
to puppet...@googlegroups.com


On Friday, April 17, 2015 at 3:25:37 AM UTC-5, jamese wrote:
I've run into the same issue before.  The way I resolved it was to add a file resource for each yum repo, just ensuring it is present.  That way, the recursive purge on /etc/yum.repos.d/ doesn't nuke the repo files that puppet has created. 


This issue relates to managing the same physical resources via multiple distinct Puppet resources.  Enabling purging on a directory brings all files in the scope of the purge under management as File resources, but in this case, some of those resources are also managed by Yumrepo resources.  If it is not an option to drop the purging, then the only way to prevent the repo files from being removed and recreated on each run is to go all the way in and bring the repo files under explicit management, as suggested.

It's never good to manage the same physical resource via multiple logical ones, but you can rationalize it in this case as partitioning the physical file into a filesystem entry and file content, and managing each of those via a separate resource.  It's not an especially good rationalization, mind you, but it may help you feel better about yourself.
 

Arguably the yumrepo type should do that but it doesn't appear to - at least not when I wrote the module I'm using, which was maybe 2-3 years ago.


Having one resource implicit in another is a bit nasty, but it sure would be convenient for this particular purpose.  You could consider filing an RFE.


John

jcbollinger

unread,
Apr 17, 2015, 9:56:08 AM4/17/15
to puppet...@googlegroups.com
Well, darn.  I even checked the type reference before posting, but it looks like I somehow landed on an older version.

Nevertheless, if it were desirable to purge the directory in order to also remove unmanaged files that do not correspond to repos, then Resources wouldn't cut it.


John

Reply all
Reply to author
Forward
0 new messages