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.
>
>
>
> 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.
Cool, I am liking the sound of it as well.
Thanks,
Devan
>
> 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(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin