In order to improve the customer experience in the Red Hat Customer Portal around subscription management we are going to need some new API's in order to show the relationships between Systems, subscriptions,contracts and status. I will add some folks to help give definitions around exactly which API's are needed.
What we are ultimately looking for is the ability to list consumers based on their subscription criteria. Listing consumers that have pools with: 1) a given subscriptionID 2) a given SKU 2) a given contract number 3) a given contract number and SKU I think our only option right now would be to get all consumers and their pools and do our own filtering.
Just to clarify, these queries will be within the context of an org. Probably an extension to the /owner/{id}/consumer resource.
(In reply to Jonathon Turel from comment #1) > What we are ultimately looking for is the ability to list consumers based on > their subscription criteria. > > Listing consumers that have pools with: > > 1) a given subscriptionID By subscription ID do you mean the entitlement ID? Or do you want to actually search via the source subscription for a given pool?
Source Subscription ID, please.
Pending merge as https://github.com/candlepin/candlepin/pull/990
Jonathon, I was just running through this code this morning and realized that the implementation may have some unforeseen quirks. Assume SystemA is subscribed to SKUs "p1" and "p2". SystemB is subscribed to "p1" only. POST /owners/my_org/consumers?sku=p1&sku=p2 The result would be [SystemA, SystemB, SystemA] since SystemA has both p1 and p2. Personally, I think that violates the principal of least astonishment. I can see it being valid to return [SystemA] (implicit AND) or [SystemA, SystemB] (implicit OR with a `uniq` applied). I tend to lean a bit towards the implicit AND because the JSON that is returned doesn't actually have any entitlement information in it. With the implicit OR + uniq, it would be impossible to subsequently narrow down whether the consumer was selected because it had p1 or p2,. The same type situation also exists with the new "subscription_id" and "contract" query parameters. Please let me know what you think.
Alex, Thanks for bringing this to my attention. The behavior I would expect would be the implicit AND as you described because of your observation about principle of least astonishment, and that's just how we'd like for it to behave in terms of our use case.
Is this not already solved in Sat6.3 with Candlepin 2.0 and the updated susbcription allocation handling in the Portal?
Thanks Peter, sending to Barnaby to look at.