Bug 1391429

Description of problem:
Assume a customer adds several subscriptions to a manifest such that:
- subscription S1 itself provides some product and entitles them to access CDN paths P1 and P2 of the product
- subscription S2 itself provides the same product and entitles them to access CDN paths P1, P2,.. P10 of the product

Then the entitlement certificate for S1 should allow accessing all P1 to P10 paths, what is not ensured nowadays.

Reasoning:

Current situation (ent.certificate for S1 allows paths P1 and P2 but not P3 to P10) prevents a customer to enable the relevant repository (for P3 path) in Satellite, since (during repo enabling):
- Satellite traverses subscriptions one by one to find first that provides relevant product for the repo - here both S1 and S2 match
- Sat uses the entitlement certificate from that (first) subscription to access content on CDN - and here S1 cant be used

Since both of the subscriptions provides (among others) the same product BUT allows just _some_ of CDN paths, the chosen entitlement certificate can't be used for accessing repo relevant for the missing CDN paths.

From Satellite6 point of view, a subscription shall provide access to whole product(*) or to nothing from the product. This is violated in that manifest.

(*) "whole product" means all CDN paths the customer is entitled to access by the set of subscriptions in the manifest

Therefore, generating manifest - during generating list of CDN paths entitled by an entitlement certificate of some subscription - needs to take into account other subscriptions and their CDN paths.

If that is not possible to achieve within candlepin, the logic of dealing with products, subscriptions and entitlement certificates within Satellite would have to be substantially changed (to traverse through all subscriptions providing the given product, and choosing the certificate that entitles the given CDN path - what is currently impossible when Satellite deals with a _product_ in this decision, not with a _repository_). That is why I am filing the BZ against candlepin - re-raise to Satellite if you think Satellite/katello change would be easier AND if such manifest is correct.

Version-Release number of selected component (if applicable):
0.9.54 (? seen in manifest generated by customer portal in Aug 2016) 


How reproducible:
100%


Steps to Reproduce:
See above for generic reproducer. Particular generated manifest from a customer to be provided in internal comment.


Actual results:
(on unpacked manifest):
# rct cat-cert export/entitlement_certificates/8023054703202613375.pem | grep resilientstorage
    URL: /content/eus/rhel/power/5/$releasever/$basearch/resilientstorage/debug
    URL: /content/eus/rhel/power/5/$releasever/$basearch/resilientstorage/os
    URL: /content/eus/rhel/power/5/$releasever/$basearch/resilientstorage/source/SRPMS
    URL: /content/eus/rhel/server/7/$releasever/$basearch/resilientstorage/debug
    URL: /content/eus/rhel/server/7/$releasever/$basearch/resilientstorage/os
    URL: /content/eus/rhel/server/7/$releasever/$basearch/resilientstorage/source/SRPMS
# rct cat-cert export/entitlement_certificates/5189219367084232490.pem | grep resilientstorage
    URL: /content/eus/rhel/power/5/$releasever/$basearch/resilientstorage/debug
    URL: /content/eus/rhel/power/5/$releasever/$basearch/resilientstorage/os
    URL: /content/eus/rhel/power/5/$releasever/$basearch/resilientstorage/source/SRPMS
    URL: /content/eus/rhel/server/7/$releasever/$basearch/resilientstorage/debug
    URL: /content/eus/rhel/server/7/$releasever/$basearch/resilientstorage/os
    URL: /content/eus/rhel/server/7/$releasever/$basearch/resilientstorage/source/SRPMS
#

cf. with:

# rct cat-cert export/entitlement_certificates/6215095075299388461.pem | grep resilientstorage
    URL: /content/eus/rhel/power/5/$releasever/$basearch/resilientstorage/debug
    URL: /content/eus/rhel/power/5/$releasever/$basearch/resilientstorage/os
    URL: /content/eus/rhel/power/5/$releasever/$basearch/resilientstorage/source/SRPMS
    URL: /content/eus/rhel/server/5/$releasever/$basearch/resilientstorage/debug
    URL: /content/eus/rhel/server/5/$releasever/$basearch/resilientstorage/os
    URL: /content/eus/rhel/server/5/$releasever/$basearch/resilientstorage/source/SRPMS
    URL: /content/eus/rhel/server/6/$releasever/$basearch/resilientstorage/debug
    URL: /content/eus/rhel/server/6/$releasever/$basearch/resilientstorage/os
    URL: /content/eus/rhel/server/6/$releasever/$basearch/resilientstorage/source/SRPMS
    URL: /content/eus/rhel/server/7/$releasever/$basearch/resilientstorage/debug
    URL: /content/eus/rhel/server/7/$releasever/$basearch/resilientstorage/os
    URL: /content/eus/rhel/server/7/$releasever/$basearch/resilientstorage/source/SRPMS
#

The customer has attached subscriptions for both Resilient Storage product
(ID 90, SKU RH00026F3) and its EUS version (ID 91, SKU RH00003),


Expected results:
both "rct cat-cert" should print the same list of CDN paths (for some product)


Additional info: