[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 08: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


* A user probably will have an easy time adding custom content to their
repos without having to create new repos


* We need to regenerate metadata for the repo. Today we get the metadata
for repos with feed directly from the feed.

to me this is the biggest annoyance from Pulp's code standpoint. Once you allow uploads you have to then always run a createrepo --update to merge the upstream repodata with the local packages.

* Will need to worry about what version of RHEL/Fedora pulp is running
on for compatible yum metadata.

how is this different than the issues we face for repos without a feed that we are required to generate repodata for? We still have to run createrepo any time we upload a package to a repo so if it has a feed or not doesn't seem to make much difference to me. Does allowing uploads to repos with a feed make this problem worse than the problems we already have?

* For Red Hat repos, we probably dont want to allow this anyway. So
we'll need some extra rules to bypass this.

perhaps just an 'allow uploads' flag on the repo. then any uploads to that repo would be blocked:

$ pulp-admin repo upload --id=test --dir=/mnt/foo

ERROR: Uploads to repo [test] are blocked because the 'allow_uploads' flag has been set to false. If you wish to enable uploads to this repository please set the allow_uploads flag to true.

The reason I prefer a flag vs just baking in some 'this is a Red Hat repo so uploads can never happen' rule is I still prefer to keep Pulp a bit more generic and not Red Hat specific. A flag allows Pulp to handle both cases.

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.

I agree it is cleaner from Pulp's standpoint but from an end user standpoint it seems like an artificial constraint we are placing on our users because we aren't taking the time to handle the case. To me this is disheartening if we had to produce the following:

$ pulp-admin repo upload --id=test --dir=/mnt/foo

ERROR: You can't upload to repo [test] because it has a feed defined. You can only upload packages to feedless repos

As a user I would be kind of annoyed if there was a use case where I wanted to mix and match content into one repository and Pulp told me I couldn't do this

I weigh towards allowing uploads into any repos even if it makes it a bit harder for us to handle the different scenarios.


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