[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pulp-list] Handling Uploads to repos with feed



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 redhat com
https://www.redhat.com/mailman/listinfo/pulp-list


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]