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.2 * 0.3 master [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 {"version":"0.3.14","result":true,"release":"1%{?dist}"} How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Automated test that revealed this bug... http://hudson.rhq.lab.eng.bos.redhat.com:8080/hudson/job/rhsm-beaker-on-premises-RHEL5/287/TestNG_Report/ 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"}]
Testing after wpoteat's fixes... Verifying Version... [root@jsefler-f14-5beakerpin proxy]# git branch 0.2 * 0.3 master [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: http://hudson.rhq.lab.eng.bos.redhat.com:8080/hudson/job/rhsm-beaker-on-premises-RHEL5/307/TestNG_Report/ Test Passed: EnsureAvailableSubscriptionsListed_Test([awesomeos-s390x, [{"productName":"Awesome OS for S390X Bits"}]]) Test Passed: EnsureConsumedEntitlementsListed_Test([awesomeos-s390x, [{"productName":"Awesome OS for S390X Bits"}]])
some push data pushed, should be a awesomeos for each of i386, i686, x86_64, ia64, s390x, ppc64, and z80