[Pulp-list] Handling Uploads to repos with feed

[Jason Dobies]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/11/2010 03:49 PM, tsanders at redhat.com wrote:
> Can someone help me understand a use case where you would want to combine the contents of 2+ external yum repos into a single pulp repo?  Flexibility is great, but we need to be sure that this functionality is worthwhile.
> 
> I get being able to mirror fedora, the Dell firmware repo, and setting up a custom repo for my internally developed tools.  Not sure I would ever want all of this in a single repo, that would seem to be confusing.  Is having my systems subscribed to one repo that much more beneficial than subscribed to 3?

This gets into some tricky areas too. What if two feeds to the same repo
provide the same package, but each are signed with a different GPG key?

What happens when the user has uploaded package A but then the feed
introduces it? Do we still keep it flagged as user-uploaded or repo-fed?
What happens if for some reason the bits are different between the two?

I'm guessing a user can delete a package he uploaded, but what about
packages that came from the feed? If they can be deleted, we'll need to
keep track of that so as to not download them again on the next pull.

What happens if the user uploads a package that's an older version than
an existing package? Are they warned about it since that's probably not
what they want to do?  (this isn't necessarily a feed/sync argument, I'm
just kinda brainstorming on all the different cases that can bite us).

I'm kinda with Todd. It sounds cool from a flexibility standpoint, but
from the prospect of determining how to handle edge cases (much less
actually testing them) it may be more of a headache than it's worth.

Regardless, I think it might be worthwhile to start to map out some of
the non-basic use cases. So far, and I may just be missing it, it seems
like we've focused on the simple case of "make a repo, sync it, bind a
consumer" without focusing too hard on maintaining a larger scale usage
of it.

> Todd
> 
> Sent from my iPhone
> 
> On Oct 11, 2010, at 3:41 PM, Jason L Connor <jconnor at redhat.com> wrote:
> 
>> Hi All,
>>
>> I figure I'll weigh in with my 2¢.
>>
>> I did initially like the idea of keeping repositories that allow package
>> upload separate from repositories with feeds. This is mighty tempting
>> given its simplicity.
>>
>> However, after reading all the arguments, Mike, Jeff, and John have had
>> some really good points. If we do not treat feeds as authoritative, and
>> as simply a batch source for packages, I think this introduces much
>> greater flexibility in the pulp management model than we had before.
>>
>> I think I'd like to see us adopt this non-authoritative view. We should:
>> * allow a repository to define more than one feed
>> * allow package upload to all repositories
>> * allow admin to pull content from one or more of the defined feeds
>> * should probably change the semantics of 'sync' to 'pull' (or
>> something similar)
>>
>> I like this model because it's actually a super-set of the functionality
>> we now offer and doesn't (theoretically) sound like it's a prohibitive
>> amount of work to get it going.
>>
>> -- 
>> Jason L Connor
>> Software Engineer
>> Systems Management and Cloud Enablement
>> Red Hat, Inc.
>> +1.919.890.8331
>> RHCT #605010081634021
>> Freenode: linear
>> _______________________________________________
>> Pulp-list mailing list
>> Pulp-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-list
> 
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list


- -- 
Jason Dobies
RHCE# 805008743336126
Freenode: jdob
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMs3C0AAoJEOMmcTqOSQHC/zMIAMZxl95FXQQxBzJ3dB3der+h
UHFLtEcNHoSoDS26DrMXFa2G7c8gpjeGcSDhtpmK27TIVSpz+vje8nqI1IvQsezH
UT6aLQE+Zvv4IjYU1vqIAvVqQpaOVQ9POV1F9hUfCDrglsag6yh8+r68hPxqnzo9
46YESv1hZOaQmm6WO1DroNZrIwnSsPsTPxadGTLhzomfqyww+soOxN7NbjVlxU8Q
6m3zOCkA65oGghrqUDzpkkFqttsNNOfqESr9Jc4NeZiXFfGhGV1Iq52SYMSGPcY1
CyqLltgZxYV/bn5lrELViGJ52P34ES3G0PsPl0mtBXMFAcOAhOtmEI8loXc7h8s=
=fDdd
-----END PGP SIGNATURE-----