[Pulp-list] Handling Uploads to repos with feed

[Pradeep Kilambi]

On 10/11/2010 01: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.
>
> 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.

Making it configurable is fine I think. I jus dont see much benefit in 
allowing users to do uploads? Keeping it generic and all that is great. 
But keeping a repo with feed has some meaning. The whole point of a feed 
to me is thats the source of content for it. If you want to upload 
content you can always do that to a feedless repo. Its only a 
restriction if we're crippling users with this. But we're not. A user 
can achieve the same by uploading to a repo and subcribing to a feed + 
feedless repo.

I just dont want us to complicate use cases, just for the sake of 
flexibility.

~ Prad

>
> Mike
>
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list