On Thu, Sep 9, 2010 at 11:29 AM, Bryan Kearney <bkearney(a)redhat.com> wrote:
On 09/08/2010 03:10 PM, Devan Goodwin wrote:
>
> Initial cut at the design is here:
>
https://fedorahosted.org/candlepin/wiki/OwnerHierarchy
>
> The hierarchy itself is easy IMO, it's the management of pools and the
> impact on our security system that will be hard.
>
> Let me know what you think.
>
> Cheers,
>
> Devan
>
Devan:
is there a hybrid model where there is something like a "grant". I am
thinking that sub owner would be a consumer in the parent. Then, we could
follow a similar model where a subscription in the child is tied to a
consumer in the parent.
This sounds pretty close to the re-use of export/import code scenario,
although just with entitlement import taking place in the app (and not
from disk), but I do feel this is more complex than it needs to be and
as such will be more error prone for us to manage. (I am assuming the
"grant" is an entitlement bind event, or something new but very
similar to it?)
In my mind, the end result we want is the sub-owner to have a pool
available to their consumers. To achieve this result I dislike the
idea of getting there via a new consumer, a new bind event +
entitlement + entitlement cert, a new subscription and then the
resulting new pool. This is a lot of objects to traverse and I'm not
sure they're all really being used as intended. Arguably a lot of the
logic would be handled recursively by our code but it still feels like
far too many moving pieces. (almost every resource we have)
OTOH I do see that it is quite similar to the hosted -> on-site import
process, and it may be good to re-use that. This was however designed
to get through situations where the sub-owner is completely
disconnected, which is not the case here.
I'm genuinely not sure which is the best way to approach this. I think
I still prefer the "keep it simple" approach, but feedback is welcome.
also.. as a stretch...
We heard from one customer that they would like to allocate a range. So..
for example.. I could "give" to a sub-owner 200 but they can use up to 500.
Tough one, I think we could do this server side via the javascript
rules (add an attribute on the pool to define the range, and let the
rules handle pulling additional entitlements off the parent pool if
they're available, and rejecting them if not).
The problem I see with it is for clients, I think we're saying that at
some point, a client tool will need to be displaying a pool that's
completely consumed, how would a user know that they could keep going?
Almost surely client tooling should not be checking attributes and
infering what to do/display based on that. I guess we could have a
rule of thumb that all client tools should still display full pools
and let the user continue trying to bind to them?
Also worth noting the impact this would have on the above approach,
the range could have implications on the top level owner's pool, the
entitlement given to the sub-owner consumer, and then the subscription
and pool in the sub-owner. Everything would need to be kept in the
correct state.
Possible but really depends on how important it is, feels quite scary.
--
Devan Goodwin <dgoodwin(a)rm-rf.ca>
http://rm-rf.ca