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

Re: [Pulp-list] Updating repo feeds?



----- "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. 








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