[Pulp-list] Minor usability problem with stale cached login credentials

[Nick Coghlan]

On 03/23/2012 10:10 PM, Jay Dobies wrote:
> On 03/22/2012 09:03 PM, Nick Coghlan wrote:
>> On 03/23/2012 04:20 AM, Jay Dobies wrote:
>>> This is one of those things that annoyed us in the beginning and after a
>>> while of never getting around to fixing it, we developed blinders and
>>> don't even notice anymore :)
>>>
>>> This sprint I'm looking to get login/logout functionality into the v2
>>> client, I'll make sure I don't fall into the same trap again.
>>
>> If you're replacing the client then I won't worry about raising the bug.
>> While I'll be using my custom client (which hooks into the v1 client
>> authentication code) for PulpDist 0.1.0, the new pulp-admin integration
>> hooks are definitely something I want to look at for 0.2.0.
>>
>> If you're curious about how my custom Pulp v2 API client currently
>> works, the docs are here:
>>
>> http://readthedocs.org/docs/pulpdist/en/latest/cli.html
>
> Nice docs :)

Sphinx + readthedocs is a very nice combo to work with. (I'd like to do 
a proper site for PulpDist at some point, but it's hard to justify the 
time required when it's just me working on it)

> It looks like you've reduced the create/add importer stuff to a single
> step in init. I'm doing the same thing for the RPM client and ran into a
> problem whose solution you might be interested in.
>
> The create repo call is pretty easy to make succeed, there's very little
> that can go wrong. The add importer call, on the other hand, has a lot
> of potential to fail due to invalid config. When that happens, I was
> left with a created repo but no importer on it and no desire to expose
> to the user where that distinction lies.

Ah, thanks. My approach to handling that case is to actually use a 
"create_or_save_repo" operation in the client - if the POST to the 
collection fails, it tries a PUT to the pre-existing repo instead.

If the importer addition fails, the partially initialised repo does get 
left around on the Pulp server, but a subsequent init call should work 
anyway.

This is due to the fact that the "init" command is intended to handle 
both initialising a site from scratch and updating the configuration of 
an existing site, so it needs to cover the case of overwriting a 
pre-existing repo regardless.

However, there's still assorted dodginess in the way that works (in 
particular, "init" will never delete repos from a Pulp server, but will 
still clobber their entries in the site metadata), so I have to revisit 
it at some point. For the moment it's in the "good enough for now" bucket.

Either way, assuming the REST API distinguishes between "failed to 
create due to bad config" and "failed to create due to an existing repo 
by that name", a combined call should simplify that part of the client 
quite a bit.

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Engineering Operations, Brisbane