[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:
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
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?


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

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
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/


Pulp-list mailing list
Pulp-list redhat com

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