Red Hat Bugzilla – Bug 975520
content availability based on arches is currently too tolerant
Last modified: 2015-05-14 10:54:04 EDT
Description of problem:
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".
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".
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
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.
Author: Adrian Likins <firstname.lastname@example.org>
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
[root@jsefler-f14-candlepin candlepin]# git show-ref | head -1
[root@jsefler-5 ~]# subscription-manager version
server type: Red Hat Subscription Management
subscription management server: 0.8.16-1
The automated test coverage that originally detected this bugzilla is now passing.
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.