übercerts

Dmitri Dolguikh dmitri at redhat.com
Mon Sep 12 13:41:02 UTC 2011


On 11-09-12 10:36 AM, Bryan Kearney wrote:
> 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
Something like:
  - as an Image Factory user I'd like to create an uebercert (an 
entitlement certficate granting access to all content for a given 
organization)
  - as an Image Factory user I'd like to be able to download an existing 
uebercert
  - as an Image Factory user I'd like to be able to re-generate 
uebercert (this one can be rolled-in into creation however)

-d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/candlepin/attachments/20110912/8a2d583d/attachment.html>


More information about the candlepin mailing list