Description of problem: ISSUE 1: The new "arches" attribute on a content set was designed to satisfy RFE bug 706187. Currently the implemented design is letting content through to the entitlement on a system whose arch is not on the content set arches list. For example, here's a log statement from an automated test that is failing... > java.lang.AssertionError: As expected, contentNamespace label 'content-label-64' defined for arches 'i386,i686' is NOT included in the entitlement after subscribing to 'My Subscription providing Arch-Based Content' on a 'x86_64' system. expected:<true> but was:<false> What's happening is that Candlepin is trying to be too smart. Although the arches for this content set have been set to "i386,i686" and the system's arch is "x86_64", Candlepin is letting this content set through because Candlepin is smart enough to know that i386,i686 packages are runnable on an x86_64 system. However, discussions with dgregor from release engineering indicate that Candlepin should honor the arches defined on a content set more literally. This example content set should only be available on a system whose arch is "i386" or "i686". If release engineering wanted this content set available on an x86_64 system too, then the arches would be defined by release engineering as "i386,i686,x86_64". ISSUE 2: The same story applies to "ppc". A content set defined with arches="ppc" should not be available via the candlepin entitlement on a system whose arch is "ppc64". If this is what release engineering wanted, then they will set the content set arches="ppc,ppc64". ISSUE 3: Another request that is not yet implemented is that Candlepin should tolerate "x86" on the content set "arches" attribute as an alias for "i386,i486,i586,i686". Release-engineering would like to specify an arches value of "x86" and then this content would be available on system's whose arch is either i386 or i486 or i586 or i686 (but not x86_64). Version-Release number of selected component (if applicable): [root@jsefler-f14-candlepin ~]# cd candlepin [root@jsefler-f14-candlepin candlepin]# git show-ref | grep master 2c62529c399083cd29a50371c51478053c1c0919 refs/heads/master
ISSUE 4: Another request that is not yet implemented is that Candlepin should tolerate "noarch" on the content set "arches" attribute to behave exactly like the "ALL" alias which is already implemented. Hence if "noarch" or "ALL" is set within the content set "arches", then it will be included in the entitlement and available on any system.
commit ef7bd57af96d2a4b11901a2887be88213788d339 Author: Adrian Likins <alikins> Date: Tue Jun 18 16:02:15 2013 -0400 make Content arch compares more specific Content for example, for 'i686' now only matches 'i686' machines (no longer matches as compatible with 'x86_64') Add support for Content arch of 'x86' that maps to i386,i486,i586,i686
Verified Version... [root@jsefler-f14-candlepin candlepin]# git show-ref | head -1 57ac1f8da3ad1abe463a5ec6179813bf707daa35 refs/heads/master [root@jsefler-5 ~]# subscription-manager version server type: Red Hat Subscription Management subscription management server: 0.8.16-1 subscription-manager: 1.8.13-1.el5 python-rhsm: 1.8.13-1.el5 The automated test coverage that originally detected this bugzilla is now passing. VerifyContentSetsEntitledFromSubscriptionPoolSatisfyTheSystemArch_Test(SubscriptionPool pool) VerifyArchRestrictedContentSetsEntitledAfterSubscribeAllSatisfiesTheSystemArch_Test() 1. Content sets with an "x86" arches value are now being granted to a consumer whose system arch is among "i386","i486","i586","i686" 2. Content sets with an arches value containing one or more "i386,i486,i586,i686,x86" are no longer being granted to a consumer whose system arch is "x86_64". 3. Content sets with a "noarch" arches value are now granted to a consumer no mater what their system arch value is. Moving to VERIFIED.