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

Re: [Pulp-list] Updating repo feeds?



On 10/15/2010 09:55 AM, John Matthews wrote:
----- "Pradeep Kilambi"<pkilambi redhat com>  wrote:

We currently have the ability in pulp to allow users to update the
feed of the existing repo. This poses some potential issues. So,

Goal of this discussion:

Is to decide if we should allow updating feed urls in existing repos.


Here are the use cases I can think of and potential issues

Case-1: New feed with same content

Pulp has an existing repo A. The feed of this repo is pointing to
http://myhostname/locationA/ and synced. Now this feed location is
moved to http://myhostname/new-locationA/ with same content. In this
case, since the new location content is same as existing synced
content, I would like to be able to update the feed url and continue
using this repo A as it is.

This case justifies the need for having an update option to feed url
in a repo.

Case-2: New feed with different content

Pulp has an existing repo A. The feed of this repo is pointing to
http://myhostname/locationA/ and synced . Now this feed location is
moved to http://myhostname/locationB/ with new content. This case
causes potential issues. I already have existing content from
locationA which most certainly will conflict with new content I'm
gonna pull down from location-B. Now in this case, I will need to
remove previously synced content from this repo and freshly sync down
from location-B for this repo to be sane. But we cannot easily
differentiate between Case-1 and Case-2 to do this. We could probably
do a checksum compare, but even that will result in wipe of the data
even if one single package is changed in the source.

Case-3: No feed

Pulp has an existing repo A. The feed of this repo is pointing to
http://myhostname/locationA/ . Now I make this repo feedless and
upload content. This also will have similar issues as case-2 but
probably less likely. As user would now upload some new packages to
this repo. If these new packages are different from existing ones,
we're good. If we have similar packgaes in the repo, we'll hit some
conflicts and checksum mismatches.

So based on these cases, Its probably a safer choice to not allow user
to update the feed url for a repo. But I can also see the need to
support case-1, where it would be a pain to create a new repo if the
same content is just moved to a new location and I would rather just
update the url and continue using the repo.

So what do you guys think.

--


Could we support the update as an advanced option, as in document this is something to only invoke if you know what you are doing? I could see the desire for Case-1, say a user migrates a feed source to a new machine.

For Case-2, we may not have a problem.  When it does the resync, pulp will read the metadata from the new source.  It will sync down the new packages, then it does a delta between previous existing packages and packages from the source metadata.  Any package marked 'repo_defined=True' and not in the source metadata will be removed.   [We need to verify this holds true for same NEVRA but different checksum, the check might need to be expanded to cover checksum].   End result potentially all previously synced packages would be deleted from the repo.  Sounds to me like the user needs to be really sure this is the behaviour they wanted, that's the main problem I see.

For Case-3, if I understand correctly, the problem is what do you do when an uploaded NEVRA conflicts with an existing package?  I'm thinking one solution would be to throw an error, and require the user to explicitly delete the package from the repo, if they want to upload their version.


+1 to John's proposal. I'll make the same case that I did for uploading packages to repos with feeds. we should support operations that users would expect to be able todo even if they possibly can introduce error conditions.

Perhaps a user was pointing at a mirror that went down and wants to switch to a different host that had the same content (Case-1). To me I could see this as being common and to block any changes to feeds because we may run into problems from Case-2 seems over-aggressive.

Mike


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