I think it would also be great if we were to use stderr to give the user a more informative error message rather than referring them to the admin.log when this happend.

I think it would also be friendlier if we offered an informative error message to the user with stderr when this happens, rather than referring them to the admin.log file.

I'm confused, we do log an error message (not stderr, that's gonna be something we move to in the future). But it doesn't refer them to admin.log:


[jdob@prosperity .pulp]$ pulp-admin login -u admin -p admin
The server hostname configured on the client did not match the name found in the
server's SSL certificate. The client attempted to connect to [localhost] but the
server returned [prosperity] as its hostname. The expected hostname can be
changed in the client configuration file.


The exception logged in admin.log isn't a problem, just the exception associated with the error. We could hide it, but I don't think its a big deal to log the error since they did in fact see an error.

Hmmm, now I am confused. I tried to reproduce the problem that I originally reported, and it now does report the friendly error message.

At the very least, something is causing the AttributeError, and we should fix that. I can't get it to tell me to look at admin.log again for some reason, so I'm not sure what condition caused that.

For now, I'm going to just continue testing other things, we can come back to this if we want.

I get the pop error as well.  for me the pulp-admin client existed with an unexpected error while tracking status of the rpm repo sync.  the sync kept running, but looks like the client took a dive.


============================


    2012-11-30 14:01:13,926 - ERROR - Client-side exception occurred
    Traceback (most recent call last):
    File "/usr/lib/python2.6/site-packages/pulp/client/extensions/core.py", line 478, in run
    exit_code = Cli.run(self, args)
    File "/usr/lib/python2.6/site-packages/okaara/cli.py", line 933, in run
    exit_code = command_or_section.execute(self.prompt, remaining_args)
    File "/usr/lib/python2.6/site-packages/pulp/client/extensions/extensions.py", line 224, in execute
    return self.method(*arg_list, **clean_kwargs)
    File "/usr/lib/python2.6/site-packages/pulp/client/commands/repo/sync_publish.py", line 101, in run
    status.display_group_status(self.context, self.renderer, task_group_id)
    File "/usr/lib/python2.6/site-packages/pulp/client/commands/repo/status/status.py", line 63, in display_group_status
    _display_status(context, renderer, task_list)
    File "/usr/lib/python2.6/site-packages/pulp/client/commands/repo/status/status.py", line 95, in _display_status
    _display_task_status(context, renderer, task.task_id, quiet_waiting=quiet_waiting)
    File "/usr/lib/python2.6/site-packages/pulp/client/commands/repo/status/status.py", line 126, in _display_task_status
    response = context.server.tasks.get_task(response.response_body.task_id)
    File "/usr/lib/python2.6/site-packages/pulp/bindings/tasks.py", line 47, in get_task
    response = self.server.GET(path)
    File "/usr/lib/python2.6/site-packages/pulp/bindings/server.py", line 84, in GET
    return self._request('GET', path, queries)
    File "/usr/lib/python2.6/site-packages/pulp/bindings/server.py", line 142, in _request
    self._handle_exceptions(response_code, response_body)
    File "/usr/lib/python2.6/site-packages/pulp/bindings/server.py", line 173, in _handle_exceptions
    raise exceptions.PulpServerException(response_body)
    File "/usr/lib/python2.6/site-packages/pulp/bindings/exceptions.py", line 28, in __init__
    self.href = response_body.pop('_href', None)
    AttributeError: 'str' object has no attribute 'pop'

The only time I've seen that sort of pop error is when Apache returns the error instead of Pulp. Apache's version won't include all of the data we're attempting to parse. I can somewhat understand that in Randy's case but much less so in Steven's.

Steven - If you can reproduce this, please attach the last 400 lines of ~/.pulp/server_calls.log to this ticket. I'd like to see the actual error message coming back.

Jason - Can you harden that response parsing to more gracefully account for a non-Pulp standard error? Let me know if you don't have time and I can do it. I'm thinking if the response body isn't a dict, we can bubble up to the client middleware a new type of exception and display that string to the user rather than losing it in this pop issue.

I don't have anything in ~/.pulp/server_calls.log matching the timestamp when I got the pop/str error.   I also wacked my pulp install over the weekend trying to tie into the git code raw.

Lemme do a fresh pulp install on another test host and see IF I can get some clean logs.

Sounds good, appreciate it Steven.

I was able to get the error.  it was due to a pulp server setup issue.

I actually just posted server and client logs for that machine for bug 88300, here is the attachment link:
https://bugzilla.redhat.com/attachment.cgi?id=657780

the str/pop issue is seen in the client logs at 2012-12-04 13:41:23

I filed this separately this morning and fixed it. Closing out as a dupe of that one.

*** This bug has been marked as a duplicate of bug 885134 ***