[katello-devel] Subscriptions - pools - entitlements clarification | API renaming proposal
Ivan Nečas
inecas at redhat.com
Mon Nov 14 14:40:17 UTC 2011
Hi there,
Referencing the "[katello-devel] Activation Keys - Subscriptions - Pools
rename" discussion we had in September, I would like to open the
discussion about naming of subscriptions/pools/entitlements.
Taking the definition that Lukas posted here in his original post:
subscription - what customer buys from us
pool - list of available entitlements
entitlement - what client consumes
So a customer buys a subscriptionl. This subscription produces a pool of
entitlements that can be consumed. When a system subscribes to a
product, an entitlement is assigned to it. Is it correct?
Question 1: why there is a separate concept of pools? Couldn't be the
subscription itself used to produce entitlements? I would like to know
the reason behind this model.
Question 2:
In our CLI there is a command:
katello system subscriptions # List subscriptions for a system
This is the same as
subscription-manager list # List subscription and product information
for this machine
sub-mgr uses also the name "subscriptions" with connection to system.
But behind the scenes it uses API
/consumer/:consumer_id/entilements
In contrast with our CLI, that uses
/systems/:system_id/subscriptions
To stay consistent and avoid maintenance issues later I suggest to
rename our API to:
/systems/:system_id/entitlements
since entitlements are the resource that the system is assigned to no
matter what name the user calls it. I propose the same rename for the UI
part of Katello. We would give the word "subscription" in our code base
the same meaning as in CP.
The reason why I'm proposing this change is the fact, that I need to
expose some API related to CP subscriptions (the customer one) and there
is no reasonable place to add it to our controllers unless I want to mix
it with entitlements.
More information about the katello-devel
mailing list