-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Between writing this up and working on >> https://bugzilla.redhat.com/show_bug.cgi?id=664040, I found that we >> permit changes to the repo that really breaks the repo in many ways. >> Assuming there are no valid use cases for changing the relative path >> after the repo has been populated, I propose following restrictions on >> 'repo update'. > >> If the repo has been populated (synced): > >> --relativepath (option rejected) > >> --symlinks (option rejected) > >> --feed (rejected if relative path (part) changed) > >> The main use case for changing the feed is that it was entered >> incorrectly when the repo was created. User tries to sync and it >> barfs. Then, the user corrects the feed URL, retries the sync and all >> is good.
I agree with the main use case and I like the idea of "you can make more changes before you do the initial sync". The feed/relativepath relationship you described may be confusing to users. We may want to make it simpler and more coarse-grained by saying they have to make sure to lock in all their values before synchronizing. If it really becomes an issue in the future we can address it. >> A secondary use case is that the user wants to sync the repo from a >> different mirror. To support this, we permit the --feed so long as the >> relative path remains the same. Ahh, ok. That's a good use case and covered by your rules. Lock in the relative path before synchronizing, but you can change the feed later. What about changing feed types? I can't think of any issues in the feed being a whole new type on an update, but figured I'd throw it out there. > - It says we can update the symlinks flag on a repo. What happens if > the > repo was already synchronized? Will we remove the packages from the repo > and replace them with symlinks? Will future syncs on that repo result in > a hybrid of full packages and symlinks? > >> Probably. Ok, that's bad, but will be covered by your rules above. > - When changing the relative path, is that something we need to > broadcast out to all bound consumers so they can update their .repo > files? If it is, that's a bug; we don't have any hooks in the update API > method. > >> Yup, this is busted. Is there a bug on it? > - You can update a group ID with --groupid, but how do you remove it > from a group? I'm going to guess this is a bug and I'll file it. > - When specifying to remove GPG keys, the docs say to specify the GPG > key file. What if they don't have the file anymore, they can't remove > that GPG key? > >> I can update the doc. Basically the user uses 'repo listkeys' and >> specifies one of the file names listed. Cool, sounds good. I just double checked and the --help is correct, so it should just be a wiki fix. > - When changing an existing --cacert, --cert, or --key is the old one > deleted from the Pulp server? Looking at the code not only do we not > delete the old ones, it doesn't look like we write the new ones to disk. > Can someone more familiar with that area confirm this is a bug? I'm going to file this as a bug too. - -- Jay Dobies RHCE# 805008743336126 Freenode: jdob http://pulpproject.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNStoOAAoJEOMmcTqOSQHCVzgIALOxA4MqVrPcjKWH/IqrN4uy dCQR4CdkRS3O5hJ29PUKnFZHVgkmCwMZUwmuGCzDnmDvYxMSP3q8NrCEzpLwafo+ 5jmyo9qoqkpQNQ7ZxVvEYVghilp+WEXZqteOu1Yh0lm+B4QwcXoRiImFT/vMnN+s wmKlYkTFuzEJS99iJeD6+4kw8BH2/5vEvxOigtvwsJ0/b2k/V/9MwvcT9FHGKJNc jsPNlJzeK7GmkYhht1CUvVK0isJruCYX9YtF6M8xLUrEEKav1VMFn8/9LRbCqQlk 6z0Cow0918dzNbnyFKGxgDNXFHQvWNo7uMAqkYYftL8q67kPHQ6lj9qiQYsk2KA= =aqfb -----END PGP SIGNATURE----- _______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
