[Pulp-list] Proof UG Additions

Jeff Ortel jortel at redhat.com
Thu Feb 3 17:03:13 UTC 2011



On 02/03/2011 10:38 AM, Jay Dobies wrote:
> -----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?

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.
>
> - --
> 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
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list




More information about the Pulp-list mailing list