[Pulp-list] Handling Uploads to repos with feed

[John Matthews]

On 10/11/2010 02:03 PM, Jason Dobies wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>    
>> 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.
>>      
> This is a good distinction. If we treat feeds the way Mike is
> suggesting, uploading a package into a repo isn't a huge issue.
>
> If we're treating the feed as the authoritative source on packages in
> that repo, then we have to take into account things like when the feed
> previously indicated package X was in it but is no longer there. Do we
> delete package X on pulp then?
>
> If we do delete package X, I don't see how we could support uploaded
> packages into a feed-backed repo. Otherwise, when we sync with the feed
> it will notice the uploaded package was not in the recent sync with the
> feed and delete it. And I'd really rather not go into the realm of
> keeping track of packages that were uploaded v. those that came from the
> feed.

I added a flag to the Package model 'repo_defined', this flag tracks if 
a Package is defined by the repo source, or if it came in some other 
way.  During a repo sync, all packages added are marked 
'repo_defined=True', otherwise if a Package is added by anything else it 
defaults to 'repo_defined=False'.  This is similar to how we handle 
package groups and custom package groups, we had thoughts of doing this 
for custom errata as well.

The issue left was how to handle yum metadata.

In regard to the whole issue of supporting this I shared Mike's 
perspective, I felt the feed was one way to get packages in and 
uploading was another valid way.  I didn't want to add limits if we 
didn't have to.



> So there's two questions here:
> - - What do we want the feed to represent, simply a one way mechanism to
> introduce packages into a repo (in which case we really should allow for
> more than one feed per repo) or the feed acting as a more authority
> figure who will keep the repo up to date with its knowledge of packages
> (in which case we may need to implement remove functionality).
> - - How does pulp currently act?
>