Unbind Proposal

Pradeep Kilambi pkilambi at redhat.com
Thu Mar 18 14:47:06 UTC 2010


On 03/18/2010 10:27 AM, Devan Goodwin wrote:
> As per meeting this morning I'd like to pitch that we replace the
> multiple unbind variants:
>
> - unbind by entitlement ID
> - unbind by product ID (actually already gone from API page after
> convos with prad)
> - unbind by certificate serial
> - unbind all
>
> With just:
>
> - unbind by entitlement ID
> - unbind all
>
> Consider that a bind creates an actual "entitlement" object and
> returns a struct to you as a result, which contains an ID specific to
> that entitlement as well as information about the pool it originated
> from, and it's product. I think this makes it fairly trivial for
> client tools or any integrating application to keep track of the
> entitlements for a specific consumer, and they can be queried at any
> time.
>
> I think we're all agreed that unbinding by certificate serial and
> product ID are both convenience methods, but I think entitlement ID is
> easy to use instead so there's little added benefit, and there are a
> couple possible future scenarios I'd like to plan for: (1) one
> consumer has multiple entitlements for one product, and (2)
> entitlements that do not have certificates.
>
> To me it seems best to keep the API as simple and explicit as
> possible, provided we're not causing excessive pain for integrating
> apps. The same argument could probably be made for unbind all, but I
> was thinking it might get ugly in the case of a kickstart where a box
> had a huge amount of entitlements, but wanted to retain it's consumer
> UUID.
>
> Keep in mind that this is just an API purity question and does not
> influence what we actually display to a user, we're not forcing them
> to pick an entitlement ID, we can still display their entitlements as
> product names and let them choose. This only implies that the client
> tools will send the entitlement ID in the background.
>
> Thoughts?
>
> Devan
>    

I understand that this makes things simpler. But from client 
perspective, unbind by product and serial are useful. Lets takes these 
cases,

- say I bind myself to "RHEL-server" this gets us back an ent object as 
you said and a cert upon getCerts. So long as I'm in the same instance I 
can use the entitlement Object in memory and do use it for unbind. Now 
user closes this instance and invokes another(GUI or cli). At this point 
I dont have entitlement object in memory, all I have for unbind is the 
product name/info from entitlement cert which we got from bind. If we're 
going to include the entitlementId in the cert, then I'm ok with this 
change. If not this is going to be an issue as we have to get back to 
the server to know what entitlement Id is for a given product I'm trying 
to unbind. I prefer not to go back to the server to get the 
entitlementId for the product I'm trying to unbind.

- Secondly lets say I want to use unbind through some script (either 
kickstart or some script talking to api) I will have no idea what an 
entitlement Id is for that product. As a user I'm either binding or 
unbinding a product not a specific entitlement.


~ Prad










More information about the candlepin mailing list