Fact 'rhsm_repos' shouldn't depend on a web API call

[tux-o-matic]

Today the only Fact shipped in this module, 'rhsm_repos', calls a sub command of subscription-manager which can take quite a while to return as it depends on API calls to Red Hat's subscription servers.
It could be more efficient to base the Fact on 'yum repolist'.

Adding 10 sec to each run on all Red Hat nodes is no good, the bright side is that the Fact wasn't committed to a valid path. Since it's not in lib/facter/, it doesn't get executed by the agent. Of course that is an issue by itself.

[bastelfreak]

Hi @tux-o-matic, thanks for reporting this. Are you able to provide a patch?
We could cache the result of the API call or switch to yum. I don't know any details, so I'm not sure which output is more appropriate to parse.

[tux-o-matic]

@bastelfreak how would you suggest to cache the result of a command called by Facter?
Calling 'yum repolist' with a grep for 'Red Hat' might be the most straight forward. I don't know how exact the result would be, for community repositories with RHEL compatible RPM the convention is to call them EL or CentOS.

[bastelfreak]

I thought of a cronjob which calls the api from time to time, the fact than just parses the cronjob output. Or: The cron writes the result into /etc/facter/facts.d/

@bbriggs Can we have your opinion here as well?

[tux-o-matic]

I can get the same output as the current Fact based on subscription-manager but 10 second fast with

yum repolist | grep "Red Hat" | cut -d " " -f 1

[bastelfreak]

Sounds way easer than deploying a cronjob/systemd timer. Can we do something with one pipe?

yum repolist | awk '/Red Hat/ {print $1}'

Can you provide a PR with a fix?

[tux-o-matic]

@bastelfreak I have one ready, can submit PR once #17 is merged.