I think some of the ElasticSearch fact formatters are not chosen correctly. They should probably be strings instead of "dates". Here's what happens when you try to index a system with something it doesn't like in this field: {"error":"MapperParsingException[Failed to parse [facts.cpu.numa_node0_cpu(s)]]; nested: MapperParsingException[failed to parse date field, tried both date format [dateOptionalTime], and timestamp number]; nested: IllegalArgumentException[Invalid format: \"0,2,4,6,8,10\" is malformed at \",2,4,6,8,10\"]; ","status":400} A customer installed RHSM on a variety of HP servers, some of which report this field as a comma-separated list, some of which report this field as a range (0-3). Regardless, this field should be more flexible. The system does get saved correctly in Katello, but it is not indexed and does not show up on the "Systems" page as a result
Prior to this system fact types were set automatically in the search server, so certain facts could be detected poorly as dates. This resulted in some systems failing to index properly due to their facts not being able to be interpreted as dates. By setting a dynamic template on the index, everything under facts will be automatically set to the string type and keyword analyzer. bd54a847b9d81bb7700677179c05edec6fd1dc84
Registered a system with "cpu.numa_node0_cpu(s)" "0-3" was able to see the system and search for facts and see that system in the filtered list. Verified, CloudForms System Engine Version: 0.1.304-1.el6
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2012-0665.html