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
}
}
$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 }
}
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" }'
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.
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.
Pull requests are always welcomed!
This module uses the Puppet Development Kit and Litmus for validation and acceptance testing. All pull requests must pass the GitHub Actions checks 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.