[Pulp-list] Proof UG Additions

[Jay Dobies]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just found another error. The update arguments table lists --key as a
valid parameter, meant for updating the repo's private key. Running
`pulp-admin repo update --help` doesn't reflect that --key is a valid
argument. I'll file that one too; leave it in the docs since it should
be there.

On 02/03/2011 12:03 PM, Jeff Ortel wrote:
> 
> 
> On 02/03/2011 10:38 AM, Jay Dobies wrote:
>>>>> 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?
> 
>> No.  I originally thought this was covered by the rules (above) but I
>> guess a user could:
>> 1) create the repo
>> 2) bind consumer(s)
>>       .... pulp.repo created on consumers .....
>> 3) update the feed or relative path
>> 4) sync.
> 
>> So the pulp.repo file will be wrong.
> 
>> I'll add a bug.
> 
> 
>>>> - 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.
> 
>>
_______________________________________________
Pulp-list mailing list
Pulp-list at redhat.com
https://www.redhat.com/mailman/listinfo/pulp-list

> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list


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

iQEcBAEBAgAGBQJNSuUHAAoJEOMmcTqOSQHCvy4IALedRtk6Ee+be9/WUfIGSGQs
gsqBs+pN6pDgqGzLmcSgCh3xYsv8CGPzENHPLnUalBxL0KVMQU2SqPUoz4mYw0Av
7zxQR8FEueMXCB07vHc2LYvZnSx90mr6YGlgZZMVV1JWHWRG5SyC5BygsZeCe1nH
k4xuSvmc7McLNSekdppO3Ahd1mcd3878ljYM/z8kLS/oMYvsHynxDb+CBtVuGQAU
nB7CihKsHXKLckDRgqH9SEvFT9kHUXKXFDk5qK49Ao/KZPJ5VD8C3/X8falYVDj0
LbA9+zrtSzYPh6N3nDYmsdife9PblIXgSBLOFxngVx802nQYWZHO7pRsasuHpTI=
=FyrA
-----END PGP SIGNATURE-----