On Fri, May 25, 2012 at 08:54:20AM -0400, Bryan Kearney wrote:
On 05/24/2012 03:30 PM, Devan Goodwin wrote:
>There are a few ways certs get regenerated:
>
>1. During refresh pools if
>(a) the product name/attributes change
>(b) provided products are added/removed
>(c) subscription dates changed
>(d) subscription was revoked
>- quantity changes could lead to certs getting revoked if we're over the
>limit, but does not regenerate anything.
>- we do not regenerate on content set changes (we do for provided
>products, but not just content sets within one of those provided
>products). we do not store content data locally in some deployments so
>there's nothing to compare against to see if anything changed.
Isnt this why we had a refresh based on product? If we dont have
this, I have a new backlog item :)
>- I am assuming the business rules would require us to immediately
>revoke for (d), but to use lazy revocation for all of the others.
Agreed.
>
>2. An explicit call to regenerate everything for some product, I do not
>know where/if IT uses this: PUT /entitlements/product/{productId} Lazy
>regeneration should probably be used here. (doesn't matter what changed,
>we don't really know, but we can rest assured it wasn't anyone losing
>their subscription access)
agreed... answers my question from above. I thought we had this already.
We have it, but it might not be used by anyone.
>
>3. An explicit call to regenerate everything for a given consumer: PUT
>/consumers/{uuid}/certificates. IMO we should not do any lazy
>regeneration here, I think the use case for this call was for security
>reasons and the like.
No, I would here as well. Or, give an option:
PUT /consumers/{uuid}/certificates?lazy=HellNo
>
>4. If configured for environments, whenever content is promoted/demoted
>to an environment, we mass regenerate for those consumers. Lazy regen
>seems good here.
Need to define lazy for me here. I would assume we would not have
distributors and environments.
>
>
>
>This seems fairly straightforward so far. The request was for
>distributor consumer types only.
>
>- Add a "dirty" column to cp_entitlement, flip it to true as desired for
>entitlements when they need regeneration during (1) or (2) above.
>
>- In GET /consumers/{uuid}/export check all entitlements for the dirty
>flag, if any are found regenerate them, then proceed normally.
>
>jbowes has proposed possibly leveraging lazy regen for all consumers of
>all types for some cert v2 purposes. (might need more info from you on
>this jbowes) I think this just implies expanding the hooks for
>triggering regeneration to:
I agree. It may be nice to have the pain of creating the new certs
at next machine checkin. This would speed up the repool by spreading
out the pain.
>
>GET /consumers/{uuid}
>GET /consumers/{uuid}/entitlements
>GET /consumers/{uuid}/certificates (both JSON and ZIP calls)
>GET /consumers/{uuid}/certificates/serials
>
>I don't think this is much more work, the method to scan for dirty
>entitlements and regenerate would be shared across all these API calls.
>The implementation is cleaner particularly in the locations where we
>decide to set dirty flag or not, if this is not specific to just one
>consumer type and path through the code.
>
>Thoughts?
>
>Thanks,
-- bk
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
-James