[Pulp-list] Handling Uploads to repos with feed

[Jeff Ortel]

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

We have slightly conflicting terms involved here.  The term 'feed' suggests that it is a 
means to populate the repo.  Basically, import packages.  However, repo 'sync' implies 
that the feed represents an authoritative source.  I know, it's only semantics but ...

>
> 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?
>
>> 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.
>>
>> Mike
>>
>> _______________________________________________
>> 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/
>
> iQEcBAEBAgAGBQJMs1F8AAoJEOMmcTqOSQHCc/gIAJeeJ8Q0IbcdnnvJhaAKwwhe
> Mqw5o9xiXYQO9se7aFIGLKLzGazjLbTwXOoCK4A/LXFYjLT45v3nx1sS2vo3GQ/q
> BKxiTOiDbcTG1hrEYM+FU77GntLew4PdRyDMbPBNr4yE1gmY8LoozV7L8/G7eyE9
> 1oYIL9UvYFMzEWkr/Om4hdc8uDhGjIxvQ3J8uii0832Qq/iLwYHSPrbzUA0o8sjJ
> dq1elWrgL7QcAV9HTnQgSFxNcGmL3/8JW0YuCMz3f+RoNjj6R9HrnJFErEhZ88Pr
> P88+s/mn1Yn2SWWnrT1wgz6LKyttJnqzAOOmeTG47FB+9BexRg2nGMfOFo14C3Q=
> =aTxN
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5126 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/pulp-list/attachments/20101011/1755d824/attachment.p7s>