übercerts

Bryan Kearney bkearney at redhat.com
Mon Sep 12 13:36:33 UTC 2011


On 09/12/2011 09:14 AM, Dmitri Dolguikh wrote:
> On 11-09-12 10:06 AM, James Bowes wrote:
>> On Fri, Sep 09, 2011 at 10:38:38AM -0300, Dmitri Dolguikh wrote:
>>> On 11-09-09 10:29 AM, Michael Stead wrote:
>>>> On 09/09/2011 09:22 AM, Dmitri Dolguikh wrote:
>>>>> I ran into an issue with how content path is being created in
>>>>> entitlement certificates generated by candlepin when working on
>>>>> übercert functionality.Übercert is an entitlement certificate
>>>>> that has a single piece of content with the url of
>>>>> "/owner_name_goes_here" (this would grant access to all urls
>>>>> below the one specified).
>>>>>
>>>>> During entitlement certificate generation candlepin prefixes all
>>>>> content urls with owner-specific prefix (/owner_name/$env in
>>>>> general case). One way to handle this situation would be to move
>>>>> allübercert-related logic to candlepin (internal candlepin api
>>>>> allows to bypass prefix addition during cert generation). This
>>>>> would also have a benefit (imo) of bypassing async cert
>>>>> regeneration, since in this particular case it would be a bit of
>>>>> an overkill.
>>>> I like this approach better. It seems a lot cleaner to me than
>>>> just adding a somewhat buried notion of "if startswith // than do
>>>> this". Would this be done as a new resource, or just bolted onto
>>>> an existing? What sort of 'übercert-related logic' are we talking
>>>> about here?
>>> I was thinking about adding a new resource - something like:
>>> /owner/:id/uebercert with POST and GET. The logic is roughly:
>>>
>>> - create a special Product "ueber_product"
>>> - create content "ueber_content"
>>> - add content to product
>>> - create subscription for "ueber_product"
>>> - refresh pools
>>> - create consumer that will be used to consume the entitlement -
>>> "ueber_consumer"
>>> - and, finally, consume the entitlement and return the certificate
>>>
>>> I'm thinking that on a subsequent POST the entitlement cert can be
>>> re-generated.
>>>
>>> -d
>>>>> Another approach would be for katello to create content with url
>>>>> in some specific form (one suggestion was to use '//' at the
>>>>> start of the url, e.g. "//ACME_Corporation"), and bypass prefix
>>>>> addition for such urls on candlepin side.
>>>>>
>>>>> I'm not a big fan of #2. Thoughts/opinions?
>>>>>
>>>>> Cheers,
>>>>> -d
>> This content prefix stuff is on the owner, and its pretty deep down in
>> the candlepin code. I'm fine with doing it in candlepin, then. the idea
>> of a specific url for it as you suggested also looks good. My only
>> concern is this is a developement only thing, right? so we'd want to
>> have an option toggle for it or something (plugin?)
> Nope, this isn't a development-only thing - uebercert is going to be
> used by image factory. Hence my preference for resource approach.
>
> -d
>>
>> -James
>>
>>

What stories should I put on the candlepin backlog for next sprint?

-- bk



More information about the candlepin mailing list