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
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
Forgive me if some of this is different from what is implemented, it is just the email equivalent of thinking out loud....
One of the concepts of Rest is that Items should have hyperlinks. Thus, when I perform a bind, I should get a document that has links to all involved objects.
I'm thinking in a purely REST approach, a bind would be a put to the bindings collection, with argumenst for the entitlement and the customer. This should return a document with, amongst other things, the binding URL. Then an unbind would be a DELETE on this URL.
So, once you perform a bind, you should have enough information to do an unbind.
On 03/18/2010 10:47 AM, Pradeep Kilambi wrote:
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
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
Another way to think of a bind is that it should be a POST to the most stable object. I'd suppose that this would be the entitlement. But again, you should get back an URL that is the BindingObject with links to the Entitlement and the consumer.
On 03/18/2010 11:36 AM, Adam Young wrote:
Forgive me if some of this is different from what is implemented, it is just the email equivalent of thinking out loud....
One of the concepts of Rest is that Items should have hyperlinks. Thus, when I perform a bind, I should get a document that has links to all involved objects.
I'm thinking in a purely REST approach, a bind would be a put to the bindings collection, with argumenst for the entitlement and the customer. This should return a document with, amongst other things, the binding URL. Then an unbind would be a DELETE on this URL.
So, once you perform a bind, you should have enough information to do an unbind.
On 03/18/2010 10:47 AM, Pradeep Kilambi wrote:
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
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
Big discussion ensued where we sorted out the vision of how this all plays together both from the candlepin server perspective and an integrating application, for this specific issue I think we decided the above proposed changes will be ok so we'll go ahead with these, plus some additional info to be added around certs and products and what type they are.
Cheers,
Devan
On 03/18/2010 01:26 PM, Devan Goodwin wrote:
Big discussion ensued where we sorted out the vision of how this all plays together both from the candlepin server perspective and an integrating application, for this specific issue I think we decided the above proposed changes will be ok so we'll go ahead with these, plus some additional info to be added around certs and products and what type they are.
Cheers,
Devan
I think with the added agreement that we would make sure the entitlementid matched the cert serial number....or was that not agreed?
Just asaw the above email. NEvermind
On 03/18/2010 03:16 PM, Adam Young wrote:
On 03/18/2010 01:26 PM, Devan Goodwin wrote:
Big discussion ensued where we sorted out the vision of how this all plays together both from the candlepin server perspective and an integrating application, for this specific issue I think we decided the above proposed changes will be ok so we'll go ahead with these, plus some additional info to be added around certs and products and what type they are.
Cheers,
Devan
I think with the added agreement that we would make sure the entitlementid matched the cert serial number....or was that not agreed? _______________________________________________ candlepin mailing list candlepin@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepinaH
candlepin@lists.fedorahosted.org