Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1337462
Description of problem:
Following exception raised in production.log while performing "yum update"
to update packages from sat6.1.9 -> Sat6.2 snap12. Though the log-level seems "warning" but following exception is being logged in production.log

==> /var/log/foreman/production.log <==
2016-05-19 04:32:23 [app] [W] failed to detect boot server: ERF12-5139 [ProxyAPI::ProxyException]: Unable to detect TFTP boot server ([Errno::ECONNREFUSED]: Connection refused - connect(2) for "qe-sat6-upgrade-rhel7.satqe.lab.eng.rdu2.redhat.co...) for Capsule https://qe-sat6-upgrade-rhel7.satqe.lab.eng.rdu2.redhat.com:9090/tftp
 | ProxyAPI::ProxyException: ERF12-5139 [ProxyAPI::ProxyException]: Unable to detect TFTP boot server ([Errno::ECONNREFUSED]: Connection refused - connect(2) for "qe-sat6-upgrade-rhel7.satqe.lab.eng.rdu2.redhat.co...) for Capsule https://qe-sat6-upgrade-rhel7.satqe.lab.eng.rdu2.redhat.com:9090/tftp
 | /usr/share/foreman/lib/proxy_api/tftp.rb:49:in `rescue in bootServer'
 | /usr/share/foreman/lib/proxy_api/tftp.rb:42:in `bootServer'
 | /usr/share/foreman/app/models/concerns/orchestration/dhcp.rb:72:in `boot_server'
 | /usr/share/foreman/app/models/concerns/orchestration/dhcp.rb:99:in `dhcp_attrs'
 | /usr/share/foreman/app/models/concerns/orchestration/dhcp.rb:20:in `dhcp_record'
 | /usr/share/foreman/app/models/concerns/orchestration/dhcp.rb:179:in `dhcp_conflict_detected?'
 | /opt/rh/rh-ror41/root/usr/share/gems/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:424:in `block in make_lambda'
 | /opt/rh/rh-ror41/root/usr/share/gems/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:231:in `call'
 | /opt/rh/rh-ror41/root/usr/share/gems/gems/activesupport-4.1.5/lib/active_support/callbacks.rb:231:in `block in halting'

Version-Release number of selected component (if applicable):

Sat[6.1.9 -> 6.2 snap12]

How reproducible:

Steps to Reproduce:
1. set sat6.2 repo
2. katello-service stop
3. yum update -y

Actual results:

Expected results:
No such exception in logs. If its a real issue then we need to fix it otherwise, we should suppress the exception, if possible.

Additional info: