Lazy Cert Regeneration Design

Bryan Kearney bkearney at redhat.com
Fri May 25 14:39:17 UTC 2012


On 05/25/2012 10:37 AM, Devan Goodwin wrote:
> On Fri 25 May 2012 09:54:20 AM ADT, 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.
>>
>>>
>>> 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
>
> Ok if there's no known use case for demanding immediate regen for a
> consumer's certs, then may as well make it default to lazy and stay
> consistent with the rest of the API.
>
>>
>>>
>>> 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.
>>
>
> Only in like a nested Katello scenario, but my hope is that we can
> proceed with this for all consumers, not just distributors. So when
> content is promoted and demoted, all affected consumers would get their
> entitlements dirty flag set and will regen when they next check in. This
> actually alleviates one of the big concerns I had after the environments
> work where promotion/demotion could be really slow. Now, you can
> promote/demote multiple times without triggering any mass regen, should
> work a lot better actually.

Agree... that makes sense.

-- bk



More information about the candlepin mailing list