- Support a Candlepin deployment where Owners can be top-level, importing their own data from an authoritative Candlepin instance.
- Each top-level owner can create sub-owners.
- Top-level owner can split their subscriptions assigning separate quantities to their sub-owners for use.
- One on-site Candlepin may be hosting multiple disjoint top-level owners, each with their own subscriptions in an upstream hosted Candlepin instance.
- Implement a simple owner hierarchy where an owner can have an optional link
to a parent owner. (Owner.getParentOwner())
- Implement a simple pool hierarchy to be used when delegating entitlements to
- Top level owner admins would have the ability to split their pools and
create a sub-pool in the other owners.
- Parent pool’s quantity would be reduced accordingly.
- In many ways this is just focusing on what we want, we have a pool in the
top level org, we want to split it and create a related pool in the
- Refresh pools will be the most challenging aspect of this.
- When refreshing a pool from a subscription, we cannot just blindly copy
the quantity onto the associated pool because that pool could have
reduced its quantity and allocated some to a sub-pool.
- If that quantity were reduced we have a messy situation and need to
determine not just how to clean up outstanding entitlements, but also to
clean up outstanding sub-pools (possibly multiple levels deep) and their
entitlements as well.
- We have not yet solved reduced quantity in Candlepin anywhere, we just
let the pool go out of compliance and plan a batch job to determine what
to do. (it just now will be a little more complex)
- When a subscription disappears, we currently delete the pool and thus all
related entitlements. This process will continue, only now deletion of a
pool will cascade to all sub-pools in sub-owners.
- Our security settings are going to throw a fit. We automatically filter out
objects in queries and block CRUD operations across owners. These will either
need to be modified to allow if within an owner hierarchy, or will have to be
thrown out entirely.
Other (less awesome) Ideas
Re-use Import Export
This was the first option to come to mind but I think it quickly begins to look
infeasible and messy. For one, much of the data in an export is already there
(products / consumer types / rules), only the Entitlement importer would be
re-usable. If so, then the process would become an upstream subscription
becomes an upstream pool, an on-site Candlepin is deployed and registered as an
upstream consumer, who then binds and obtains entitlments with a quantity. The
export is generated and then imported on-site, those entitlements now translate
into a new subscription and then a pool on-site.
If we were to continue with this, the whole process would be repeated for each
sub-org leading to a proliferation of subscriptions and pools, all of which
need to be kept in sync. This seems like a recipe for problems when considering
the worst case scenario where a subscription is reduced. It’s also arguably a
mis-use of the Subscription, at this point it isn’t really a Subscription, and
perhaps we should only be dealing with pools during this process.
These are the pools which have a source entitlement link, intended for things
like developer licenses a person consumes and then starts using a sub-pool for
To re-use this, sub-owners would require a consumer in the top level org. If
this were in place, they could bind and create entitlements with a quantity,
and then a sub-pool would be created in the sub-org which links to the parent
I consider this a promising possibility, but still more complicated than it
needs to be. All we really want is a sub-owner with a sub-pool, requiring that
sub-owner to be represented by a consumer and bind (generating entitlement
certificates) complicates the process and adds more moving parts to keep track
of, particularly when time comes to sync up with the upstream subscription. IMO
the simpler the better, given the complexity we’re headed for.
Last modified on 12 September 2016