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

Re: [Pulp-list] Proof UG Additions





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


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