[Pulp-list] Proof UG Additions

[Jay Dobies]

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