Bug 1248066 - Discovery of a host matching an auto-discovery rule throws ISE
Discovery of a host matching an auto-discovery rule throws ISE
Status: CLOSED WORKSFORME
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Discovery Plugin (Show other bugs)
6.1.0
Unspecified Unspecified
unspecified Severity unspecified (vote)
: Unspecified
: --
Assigned To: satellite6-bugs
Katello QA List
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-07-29 10:10 EDT by Maxim Burgerhout
Modified: 2015-09-01 10:18 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-01 10:18:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
trace for when VM match auto discovery rule (28.65 KB, text/plain)
2015-07-29 10:11 EDT, Maxim Burgerhout
no flags Details

  None (edit)
Description Maxim Burgerhout 2015-07-29 10:10:57 EDT
Description of problem:
When using an auto-discovery rule like I get an ISE when my discovery machine actually matches the rule.

Version-Release number of selected component (if applicable):
foreman-1.7.2.32-1.el7sat.noarch
foreman-compute-1.7.2.32-1.el7sat.noarch
foreman-debug-1.7.2.32-1.el7sat.noarch
foreman-discovery-image-2.1.0-32.el7sat.noarch
foreman-gce-1.7.2.32-1.el7sat.noarch
foreman-libvirt-1.7.2.32-1.el7sat.noarch
foreman-ovirt-1.7.2.32-1.el7sat.noarch
foreman-postgresql-1.7.2.32-1.el7sat.noarch
foreman-proxy-1.7.2.5-1.el7sat.noarch
foreman-selinux-1.7.2.13-1.el7sat.noarch
foreman-vmware-1.7.2.32-1.el7sat.noarch
puppet-foreman_scap_client-0.3.3-9.el7sat.noarch
ruby193-rubygem-foreman_bootdisk-4.0.2.13-1.el7sat.noarch
ruby193-rubygem-foreman_discovery-2.0.0.18-1.el7sat.noarch
ruby193-rubygem-foreman_docker-1.2.0.18-1.el7sat.noarch
ruby193-rubygem-foreman_gutterball-0.0.1.9-1.el7sat.noarch
ruby193-rubygem-foreman_hooks-0.3.7-2.el7sat.noarch
ruby193-rubygem-foreman_openscap-0.3.2.10-1.el7sat.noarch
ruby193-rubygem-foreman-redhat_access-0.2.1-1.el7sat.noarch
ruby193-rubygem-foreman-tasks-0.6.15.4-1.el7sat.noarch
rubygem-hammer_cli_foreman-0.1.4.14-1.el7sat.noarch
rubygem-hammer_cli_foreman_bootdisk-0.1.2.7-1.el7sat.noarch
rubygem-hammer_cli_foreman_discovery-0.0.1.10-1.el7sat.noarch
rubygem-hammer_cli_foreman_docker-0.0.3.9-1.el7sat.noarch
rubygem-hammer_cli_foreman_tasks-0.0.3.5-1.el7sat.noarch
satellite.deployment6.lan-foreman-client-1.0-1.noarch
satellite.deployment6.lan-foreman-proxy-1.0-1.noarch
satellite.deployment6.lan-foreman-proxy-client-1.0-1.noarch

foreman-discovery-image-2.1.0-32.el7sat.noarch
ruby193-rubygem-foreman_discovery-2.0.0.18-1.el7sat.noarch
rubygem-hammer_cli_foreman_discovery-0.0.1.10-1.el7sat.noarch
rubygem-smart_proxy_discovery-1.0.2.1-1.el7sat.noarch


How reproducible:


Steps to Reproduce:
1. Create auto discovery rule, like disk_count > 2 or model = "Standard PC.."
2. Create VM that matches said rule and boot it
3. 

Actual results:
System matches rule, but long trace shows up in foreman/production.log containing "can't convert Fixnum into String (TypeError)"

Expected results:
System matches rule, reboots, provisions

Additional info:
Trace attached.
Possibly related to bug 1190601?
Comment 1 Maxim Burgerhout 2015-07-29 10:11:32 EDT
Created attachment 1057327 [details]
trace for when VM match auto discovery rule
Comment 2 Lukas Zapletal 2015-08-17 07:42:35 EDT
Hello, it looks like your problem is in provisioning templates rather than rules or discovery.

Can you please try to create new host using the very same hostgroupset as you use in the rule and then click on Preview templates (all of them). Once you identify which template is problematic, please pastebin it here. Have you changed any of the standard templates?
Comment 3 Maxim Burgerhout 2015-08-31 11:20:02 EDT
Just tried to make it break again, but I can no longer reproduce it on my current GA rig. Might have been a human error, can no longer verify.

Feel free to close this bug. Sorry for the long response time.
Comment 4 Brad Buckingham 2015-09-01 10:18:22 EDT
Maxim, I am going to close the bug for now; however, if you do encounter the behavior again, please do reopen.  Thanks!

Note You need to log in before you can comment on or make changes to this bug.