Lazy Cert Regeneration Design

James Bowes jbowes at redhat.com
Fri May 25 17:30:44 UTC 2012


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 at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin

-James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/candlepin/attachments/20120525/44113a41/attachment.sig>


More information about the candlepin mailing list