Questions:
- Should we change the straight activation key to pool relationship.
From what I heard the other day it's not just a relation to a pool,
but will also require a quantity, which probably implies some kind of intermediary object.
- Could an activation key ever reference a product rather than a specific pool?
- Is there anything else our activation keys will need to do?
- What restrictions should be placed on activation key text? I'm a fan of the alpha-numeric + "-" and "_" for things like this.
- Are we expecting these to be operational at the end of this sprint? Or just that you can pass them in during registration but nothing will happen.
Thanks,
Devan
On 07/15/2011 03:09 PM, Devan Goodwin wrote:
Questions:
- Should we change the straight activation key to pool relationship.
From what I heard the other day it's not just a relation to a pool,
but will also require a quantity, which probably implies some kind of intermediary object.
One use case for keys is just to bypass authentication... so.. the following are valid
FOO bypasses auth BAR bypasses auth and Subscribes the consumer to 2 of product X. BAZ bypasses auth and Subscribes the consumer to 2 of product X and 3 of product Y.
- Could an activation key ever reference a product rather than a specific pool?
I dont know what this would buy us. If you want that, use subscribe --auto. Maybe in the future you pick the best match for "product X". So.. maybe in the futue.r
- Is there anything else our activation keys will need to do?
for pure candlepin, dont think so.
- What restrictions should be placed on activation key text? I'm a fan
of the alpha-numeric + "-" and "_" for things like this.
+1
- Are we expecting these to be operational at the end of this sprint?
Or just that you can pass them in during registration but nothing will happen.
I expect to see FOO from above operational. I dont think we put BAR or BAZ into the sprint. I would love to see those work tho :)
-- bk
On Fri, Jul 15, 2011 at 4:15 PM, Bryan Kearney bkearney@redhat.com wrote:
On 07/15/2011 03:09 PM, Devan Goodwin wrote:
Questions:
- Should we change the straight activation key to pool relationship.
From what I heard the other day it's not just a relation to a pool,
but will also require a quantity, which probably implies some kind of intermediary object.
One use case for keys is just to bypass authentication... so.. the following are valid
FOO bypasses auth BAR bypasses auth and Subscribes the consumer to 2 of product X. BAZ bypasses auth and Subscribes the consumer to 2 of product X and 3 of product Y.
- Could an activation key ever reference a product rather than a specific
pool?
I dont know what this would buy us. If you want that, use subscribe --auto. Maybe in the future you pick the best match for "product X". So.. maybe in the futue.r
- Is there anything else our activation keys will need to do?
for pure candlepin, dont think so.
- What restrictions should be placed on activation key text? I'm a fan
of the alpha-numeric + "-" and "_" for things like this.
+1
- Are we expecting these to be operational at the end of this sprint?
Or just that you can pass them in during registration but nothing will happen.
I expect to see FOO from above operational. I dont think we put BAR or BAZ into the sprint. I would love to see those work tho :)
-- bk
Would it be ok to add these into this sprint:
- add the key string validation as discussed - solidify REST calls for the org-admin management (need to shuffle some rest calls around, and add validation on the key in URLs) - disable the pool add/remove methods on the key until we can get this designed and implemented, I think that API might change once we do (just want to avoid anyone starting to call it)
If time permits later in the sprint, maybe design out that pool (or possibly product) + quantity and it's respective API calls, and try to get it operational. Initially I'm thinking maybe make it a resource (AutoEntitlement) which carries a pool or product ID and a quantity for now.
Cheers,
Devan
On 07/15/2011 03:35 PM, Devan Goodwin wrote:
On Fri, Jul 15, 2011 at 4:15 PM, Bryan Kearneybkearney@redhat.com wrote:
On 07/15/2011 03:09 PM, Devan Goodwin wrote:
Questions:
- Should we change the straight activation key to pool relationship.
From what I heard the other day it's not just a relation to a pool,
but will also require a quantity, which probably implies some kind of intermediary object.
One use case for keys is just to bypass authentication... so.. the following are valid
FOO bypasses auth BAR bypasses auth and Subscribes the consumer to 2 of product X. BAZ bypasses auth and Subscribes the consumer to 2 of product X and 3 of product Y.
- Could an activation key ever reference a product rather than a specific
pool?
I dont know what this would buy us. If you want that, use subscribe --auto. Maybe in the future you pick the best match for "product X". So.. maybe in the futue.r
- Is there anything else our activation keys will need to do?
for pure candlepin, dont think so.
- What restrictions should be placed on activation key text? I'm a fan
of the alpha-numeric + "-" and "_" for things like this.
+1
- Are we expecting these to be operational at the end of this sprint?
Or just that you can pass them in during registration but nothing will happen.
I expect to see FOO from above operational. I dont think we put BAR or BAZ into the sprint. I would love to see those work tho :)
-- bk
Would it be ok to add these into this sprint:
- add the key string validation as discussed
- solidify REST calls for the org-admin management (need to shuffle
some rest calls around, and add validation on the key in URLs)
- disable the pool add/remove methods on the key until we can get this
designed and implemented, I think that API might change once we do (just want to avoid anyone starting to call it)
If by this you mean I can only CRUD keys with no associations to pools, then I am fine with that. My main goal is to have the api for subscription manager locked down.
If time permits later in the sprint, maybe design out that pool (or possibly product) + quantity and it's respective API calls, and try to get it operational. Initially I'm thinking maybe make it a resource (AutoEntitlement) which carries a pool or product ID and a quantity for now.
Sounds good.
-- bk
candlepin@lists.stg.fedorahosted.org
-
Bryan Kearney -
Devan Goodwin