Lazy Cert Regeneration Design

[Devan Goodwin]

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.
   - I am assuming the business rules would require us to immediately 
revoke for (d), but to use lazy revocation for all of the others.

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)

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.

4. If configured for environments, whenever content is promoted/demoted 
to an environment, we mass regenerate for those consumers. Lazy regen 
seems good here.



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:

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,

Devan