Yumrepo Fact
This module adds a custom Facter fact that shows the number of enabled and/or disabled yum repositories on RedHat-like servers.
[root@centos7 ~]# facter -p yumrepos
{
enabled => [
"base",
"updates",
"dev_apps",
"puppet_enterprise"
],
disabled => [
"base-source",
"updates-source",
"extras",
"extras-source",
"fasttrack"
],
count => {
enabled => 4,
disabled => 5,
total => 9
}
}
Example Usage
$number_of_repos = $facts['yumrepos']['count']['total']
file { '/etc/motd':
ensure => file,
content => "This node has ${number_of_repos} yum repos on it."
}
if 'corportate-repo' in $facts['yumrepos']['enabled'] {
package { 'foo': ensure => present }
} else {
package { 'bar': ensure => present }
}
Inventory and Reporting Examples
The yumrepos fact can be queried out of PuppetDB to do basic inventory or reporting.
# Show the value of the yumrepos fact on all nodes.
puppet query 'facts[certname, value] { name = "yumrepos" }'
Reference
The output of the fact is a hash that contains the following keys:
-
enabled
: An array of the names of enabled repos. -
disabled
: An array of the names of disabled repos. -
count
: A hash that contains the following sub keys:-
enabled
: Integer - number of enabled repos. -
disabled
: Integer - number of disabled repos. -
total
: Integer - total number of repos.
-
How it works
This fact uses Puppet's resource abstraction layer to list all the local yumrepo resources on a node. Effectively, this fact is doing a puppet resource yumrepo
and parsing the enabled
attribute to determine if a repo is enabled or not.
The name of each yum repo is coming from the title of the relevant yumrepo
resource type.
Another way to view yum repos is with the command, yum repolist
. I chose not to use that because that would mean shelling out to a system command rather than staying in Ruby land. I haven't done any benchmarking, but I'm guessing it's faster this way.
Contributing and Development
Pull requests are always welcomed!
This module uses the Puppet Development Kit, Litmus, and TravisCI for validation and acceptance testing. All pull requests must pass the TravisCI tests before they can be merged.
For local development, here's the workflow I use and what I recommend you use as well:
-
Create a feature branch.
-
Make your changes.
-
Update any docs or README's if user-facing things change.
-
Validate syntax and style:
pdk validate
-
Run local Litmus acceptance tests (note: this requies a functioning local Docker installation):
pdk bundle exec rake 'litmus:provision[docker, centos:7]' pdk bundle exec rake 'litmus:install_agent[puppet]' pdk bundle exec rake 'litmus:install_module' pdk bundle exec rake 'litmus:acceptance:parallel' pdk bundle exec rake 'litmus:tear_down'
-
Push up your branch to your fork and make a Pull Request.