Bug 1329385
| Summary: | Connection fails with cryptic message when Kerberos is enabled in Mac OS X | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine-sdk-python | Reporter: | Fabrice Bacchella <fabrice.bacchella> |
| Component: | Core | Assignee: | Ondra Machacek <omachace> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Pavel Stehlik <pstehlik> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.6.5.0 | CC: | bugs, fabrice.bacchella, gklein, mperina |
| Target Milestone: | ovirt-4.0.0-beta | Flags: | omachace:
ovirt-4.0.0?
rule-engine: planning_ack+ omachace: devel_ack+ rule-engine: testing_ack? |
| Target Release: | 4.0.0a | ||
| Hardware: | Unspecified | ||
| OS: | Mac OS | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-07-27 13:02:19 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1329323 | ||
|
Description
Fabrice Bacchella
2016-04-21 19:07:30 UTC
It probably means that the version of libcurl in that system hasn't been compiled with Kerberos support. Can you check it? $ curl --version | grep Kerberos If that is the reason then we can check it earlier, and generate a better error message. That's not the point. I don't want an explicit check on Kerberos, I want a translation of (4, '') Is that a SSL error, authentication error, TCP error ? When did the connexion fails ? A what phase ? Adding debug change nothing. If I know that's an authentication error, I will start to look at curl and kerberos. But perhaps it's also an SSL error, the negotiation might have failed because I miss a cipher. I don't like wild guess when debugging, I prefer helpful informations that save time. I don't have a translation of (4, ''), and I can't reproduce your problem, as I don't have a Mac OS X environment to test it. If you want progress with this issue please provide the information that I requested. The problem is here :
except pycurl.error as error:
raise errors.ConnectionError(error)
So you have a pycurl exception and wrap it inside a ovirt exception. The message "(4, '')" is from pycurl, but I have no way to know that. And also if I look at ConnectionError:
class ConnectionError(Exception):
def __init__(self, expect):
Exception.__init__(self, '[ERROR]::oVirt API connection failure, %s' % expect)
The original exception is not kept, only it's message, so I can't dig inside it, to found where the error is coming from in pycurl. And there is a typo I think, it should be except, not expect.
Just adding a indication to look at pycurl error code would have been helpful. I found them here:
https://curl.haxx.se/libcurl/c/libcurl-errors.html
CURLE_NOT_BUILT_IN (4)
A requested feature, protocol or option was not found built-in in this libcurl due to a build-time decision. This means that a feature or option was not enabled or explicitly disabled when libcurl was built and in order to get it to function you have to get a rebuilt libcurl.
So indeed your guess was right, kerberos is missing, but I have no help from the sdk about that and needs to open a ticket to found out. That's not very efficient.
Thanks, that is helpful. We can add the complete backtrace to the exception, and maybe translate the pycurl error code into an string, if pycurl supports that. Just add the original exception in ConnectionError:
class ConnectionError(Exception):
def __init__(self, except):
...
self.original_exception = except
So end user can choose to print the stack or not, depending of his own use case, log level, and difficulty of the exception.
Can you submit a patch for that? I will have a look. I'm looking at https://github.com/fbacchella/ovirt-engine-sdk/tree/sdk_3.6 And I see: This requires that the Maven artifacts are available either locally or in an accessible remote Maven repository. As those artifacts aren't currently published to any public Maven repository, this means that you will have to build the engine first. So trying to patch the python sdk seems to be quite an adventure. I don't think I have time to test. Not tested code is always broken, I'm not sur I can provide useful help then. This bug was fixed and is slated to be in the upcoming version. As we are focusing our testing at this phase on severe bugs, this bug was closed without going through its verification step. If you think this bug should be verified by QE, please set its severity to high and move it back to ON_QA |