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