Lazy Cert Regeneration Design

James Bowes jbowes at redhat.com
Fri May 25 17:50:27 UTC 2012


On Thu, May 24, 2012 at 04:30:32PM -0300, Devan Goodwin wrote:
<snip> 
> 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:
> 
> 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?
>

My thinking on making regens lazy for all consumer types:
 1. spread x509 related load out across time. systems check in every 4
    hours or whatever, not all at once.
 2. with multiple certificate formats, there's no need to know what
    version the consumer wants before they ask for it. we simply
    regenerate what they ask for (via api or looking at a header on the
    request or whatever).
 3. fewer special cases make for cleaner code
 4. if we want to be nice to distributors and let them use certs that
    aren't exactly current, shouldn't we extend the same courtesy to system
    consumers?

Doing a lazy regen implies that the real work of deciding if a
certificate is still good is when we put that old certificate on the CRL
list. We'd only add a certificate to the CRL immediately if it has
recieved a detectable net loss in access to content, like:
- quantity of entitlement has decreased (not sure if this is a real
  thing or not)
- content set is removed from a product (not detectable?)
- content set url is changed on a product (not detectable?)
- product is removed from a subscription

If we hit one of those cases on a refreshpools, we add the cert cerial
to the CRL, and mark it as dirty, letting the client trigger the regen
at some later point.

If we don't hit one of those cases, like if we've added a new product,
we simply mark the cert as dirty. That dirty cert is still valid until
the new  regen is done, but why not just keep it valid for as long as
the newly regenerated version? that is, can we reuse the cert serial on
the new cert, keeping the old version still valid, and reducing both the
clutter in our CRL and the rate at which we consume cert serials? I
think that would work.


> Thanks,
> 
> Devan
> _______________________________________________
> 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/68e5b12c/attachment.sig>


More information about the candlepin mailing list