[Pulp-list] Handling Uploads to repos with feed

[Mike McCune]

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.

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.

Mike