[Pulp-list] Handling Uploads to repos with feed

[Jeff Ortel]

On 10/11/2010 12:55 PM, Mike McCune wrote:
> On 10/11/2010 10:37 AM, Jeff Ortel wrote:
>>
>>
>> On 10/11/2010 12:22 PM, Mike McCune wrote:
>>> On 10/11/2010 10:20 AM, Jeff Ortel wrote:
>>>>
>>>>
>>>> On 10/11/2010 10:17 AM, Pradeep Kilambi wrote:
>>>>> Should we allow the case where, user creates a repo with a feed, syncs
>>>>> down the content and then tries to upload additional content to the
>>>>> same
>>>>> repo?
>>>>>
>>>>> Pros:
>>>>>
>>>>> * A user probably will have an easy time adding custom content to
>>>>> their
>>>>> repos without having to create new repos
>>>>>
>>>>> Cons:
>>>>>
>>>>> * We need to regenerate metadata for the repo. Today we get the
>>>>> metadata
>>>>> for repos with feed directly from the feed.
>>>>> * Will need to worry about what version of RHEL/Fedora pulp is running
>>>>> on for compatible yum metadata.
>>>>> * For Red Hat repos, we probably dont want to allow this anyway. So
>>>>> we'll need some extra rules to bypass this.
>>>>>
>>>>> Overall seems like keeping uploads separate from feed repos is
>>>>> cleaner.
>>>>> User can always create a new repo, upload content and subscribe to
>>>>> both
>>>>> repos to get that additional content.
>>>>
>>>> Agreed, we should keep them separate.
>>>>
>>>> Also, we discussed (in imanage) supporting repos which extend other
>>>> repos. If we still
>>>> intend to do this, then users can easily create a repo with no feed
>>>> that extends a repo
>>>> that does have a feed. This mitigates the need to subscribe to both
>>>> repos.
>>>>
>>>
>>> I still don't see why it is all that different than what we have now
>>> with the addition of the need to run createrepo --update after a sync
>>> like we do now after a package upload ...
>>>
>>> Is there something more than that?
>>
>> For me, preventing uploads to repos with feeds has nothing to do with
>> the overhead of
>> running 'createrepo --update' but instead has to do with preserving
>> the integrity of repos
>> with feeds. I think there is some expectation that repos with feeds
>> are exactly
>> synchronized with the feed (repo). Perhaps, my perspective of what the
>> /feed/ represents
>> is incorrect?
>>
>
> good point ..
>
> to me a feed is just a way to get packages into a repo and uploads are
> another way. I don't think we said anywhere that by defining a feed for
> a repo we have a contract to ensure that the package content in the
> upstream is exactly the same as is on the pulp server. That said I do
> see where you are coming from and I expect some people do see repos with
> feeds as behaving this way.
>
> I just don't want to keep going down a path where we constrain pulp to
> work the way Red Hat releases and manages content. I still see the
> project as having the goal to be a generic software
> distribution/management tool and not something who's job is to enforce
> workflow. If users want to mix content into one repo by uploading
> packages from a local dir and feeding them in from an external source I
> think we should let them do that.

Fair enough.

>
> If we want to start putting rules, restrictions and policy around how
> content flows into a repo I think we should make it optional and
> configurable.

Agreed.

>
> Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5126 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20101011/d10d2fab/attachment.p7s>