Bug 712502 - candlepin is using fact "cpu.architecture" for rule checks when no clients actually have this fact
candlepin is using fact "cpu.architecture" for rule checks when no clients ac...
Product: Candlepin
Classification: Community
Component: candlepin (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: William Poteat
John Sefler
Depends On:
Blocks: rhsm-rhel62 568421 675214
  Show dependency treegraph
Reported: 2011-06-10 15:37 EDT by John Sefler
Modified: 2015-05-14 11:23 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-01-04 10:31:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Sefler 2011-06-10 15:37:37 EDT
Description of problem:
An automated test on s390x ran into a test failure using the TESTDATA on an s390x client such that the test was parsing json for all the subscriptions and because it found a subscription that contained a product with an "arch" attribute that was equal to "s390x" and the "sockets" attribute value was >= the sockets on the box, then the test tried to assert that a call to subscription-manager list --available should show the product subscription "awesomeos-s390x" as being available.  Unfortunately the subscription was not reported as available and the test failed.

I did some troubleshooting with alikins and we found that candlepin is looking for a client fact called "cpu.architecture".
However, on a rhel6 client, the fact was changed to "lscpu.architecture" and on a rhel57 client, there is no "lscpu.architecture" fact.  Therefore we are busted on products that specify an "arch" attribute other than "ALL".

Since both RHEL6 and RHEL57 client already have a fact called "uname.machine" which I suspect is populated by a call to "uname -i" and probably works on all the client arches and rhel versions, I suspect a change to candlepin to use "uname.machine" would be better.

Version-Release number of selected component (if applicable):
[root@jsefler-f14-5candlepin proxy]# git branch
* 0.3
[root@jsefler-f14-5candlepin proxy]# git show-ref | grep 0.3
07a8142320ebed3550cee40669f542aafa391253 refs/heads/0.3
07a8142320ebed3550cee40669f542aafa391253 refs/remotes/origin/0.3
[jsefler@jsefler ~]$ curl -k -u admin:admin https://jsefler-f14-5candlepin.usersys.redhat.com:8443/candlepin/status

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Automated test that revealed this bug...

EnsureAvailableSubscriptionsListed_Test 	6.912s 	Method arguments: "awesomeos-s390x", [{"productName":"Awesome OS for S390X Bits"}]
EnsureConsumedEntitlementsListed_Test   	 6.714s  	 Method arguments: "awesomeos-s390x", [{"productName":"Awesome OS for S390X Bits"}]
Comment 2 John Sefler 2011-06-14 14:12:57 EDT
Testing after wpoteat's fixes...

Verifying Version...
[root@jsefler-f14-5beakerpin proxy]# git branch
* 0.3
[root@jsefler-f14-5beakerpin proxy]# git show-ref | grep 0.3
9b5e7e2294b8aba41249fd7507173da9335d065e refs/heads/0.3
9b5e7e2294b8aba41249fd7507173da9335d065e refs/remotes/origin/0.3

I re-ran the automated test that originally found the bug, and now the test passes happily:

Test Passed: EnsureAvailableSubscriptionsListed_Test([awesomeos-s390x, [{"productName":"Awesome OS for S390X Bits"}]])
Test Passed: EnsureConsumedEntitlementsListed_Test([awesomeos-s390x, [{"productName":"Awesome OS for S390X Bits"}]])
Comment 4 Adrian Likins 2011-06-14 14:36:42 EDT
some push data pushed, should be a awesomeos for each of i386, i686, x86_64, ia64, s390x, ppc64, and z80

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