[katello-devel] provider URL: reverted a few changes

[Todd B Sanders]

On 05/20/2011 08:36 AM, Bryan Kearney wrote:
> On 05/20/2011 08:25 AM, Todd B Sanders wrote:
>> On 05/20/2011 08:20 AM, Bryan Kearney wrote:
>>> On 05/20/2011 07:30 AM, Todd B Sanders wrote:
>>>> On 05/19/2011 06:47 PM, Bryan Kearney wrote:
>>>>> This one was my fault. Lemme explain my thinking:
>>>>>
>>>>> If this is just for RedHat providers, then I think that the manifest
>>>>> should have it embedded or it should be coded in the app (config 
>>>>> file).
>>>>>
>>>>> Now.. should we support using the same Provider type for upstream
>>>>> candlepins? If so, that negates the idea of the config file.. but may
>>>>> be that we add it into the maniest.
>>>>
>>>> If the katello-instance that you can sync from is equal to the same
>>>> instance that created the manifest, then absolutely I would move to
>>>> embedding this data in the manifest vs the UI or config file.
>>>>
>>>> -Todd
>>>>
>>>
>>>
>>> OK... I will get this on the Candlepin backlog. As for the second
>>> question. Do we want to support the following:
>>>
>>> 1) a Tenant either gets Red Hat Subscriptions from an upstream
>>> candlepin, or Red Hat. This means there is only on Red Hat provider
>>> per tenant.
>>>
>>> -- bk
>>
>> I think that's right. Tenants are limited to a single RH provider. I
>> can't think of a case where a tenant would want to get RH content from
>> multiple locations.
>
> ok.. but the red hat provider will be for Red Hat _or_ upstream 
> candlepin?

Both.  That was my assumption; and that is determined by where the 
manifest was generated.
>
>>
>> We will need to specify the %env tag within the content set urls when
>> creating a manifest on an upstream katello/candlepin, so that the
>> downstream created RH provider will pull content from the correct
>> environment (i.e. production).
>
> Currenlty conent out of katello should be prepended with 
> /{OWNER_ID}/$env where OWNER_D is actually filled in.

Right.  My point is that $env will need to be filled in as well, 
otherwise a downstream katello won't be able to resolve a proper url to 
sync content from.  Of course I suppose we could use .listing files in 
the repos themselves (as we do for $releasever and $basearch) if the 
desired behavior was to give them access to repos in *all* environments 
on the upstream.  I'm not sure I would go that route though.

-Todd
>
>>
>> -Todd
>>
>