| Summary: | Unable to route to the repo host from here, and SSH tunnel will never be established | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] CloudForms Cloud Engine | Reporter: | James Laska <jlaska> | ||||
| Component: | oz | Assignee: | Ian McLeod <imcleod> | ||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Martin Kočí <mkoci> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 1.0.0 | CC: | brad, calfonso, jturner, whayutin | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-04-18 11:41:49 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
James Laska
2012-03-21 14:06:26 UTC
It sounds like there are multiple things going on here, as the push should be taking place at a different time than the instance trying to phone home. But I'm not qualified to debug deeper. Ian? This error means, pretty unequivocally, that the repo exposed by system engine is failing, at least intermittently. We attempt to reach the repo locally and from the running EC2 guest in this function: https://github.com/aeolusproject/oz/blob/master/oz/RedHat.py#L864 For the Factory/oz host side of things all we do here is set up a curl transaction to grab the repo metadata file. If this is successful, that counts as the repo being reachable. If not, it fails. In this case it is failing. If load is playing a role it may be on the System Engine SSL server side of things. The relevant curl error is earlier in the log: 2012-03-20 10:46:23,683 DEBUG oz.Guest.RHEL6RemoteGuest thread(2bd73c46) Message: Unable to route to the repo host from here, and SSH tunnel will never be established 2012-03-20 10:46:23,683 DEBUG oz.Guest.RHEL6RemoteGuest thread(2bd73c46) Message: (56, 'SSL read: errno -12192') So, I'd like to ask that you first address this issue to the System Engine guys, as it seems to be an error with their component. James, am going to NEEDINFO you and ask that you comment on the above analysis and, if you agree, please change the component to system engine (or clone the bug to system engine). Hi Ian ... Chris can speak more to this as he helped debug the issue while the problem was happening. I recognize there isn't a lot to go on with this bug. Additionally, QE is still trying to reliably reproduce this failure. But I thought this might be important enough to at least get the foot in the bz door. I was able to confirm that I could access the System Engine hosted repository using the appropriate key and cert. From everything I could determine while working with SSH tunnel issues in the past, System Engine appeared to be doing things correctly. We had no trouble building and pushing images (with the same templates) to other internal cloud providers. Not sure why this got moved to MODIFIED, moving back to NEW as investigation is still underway. (In reply to comment #2) > If load is playing a role it may be on the System Engine SSL server side of > things. I just re-read your comment and caught the above line. I'll move this to needinfo? on me, and attempt to determine if System Engine load could have played a role. I'm closing this bug as INSUFFICIENT_DATA. I've not encountered this since the original filing. I have been unable to recreate the condition that caused the curl command (issued from oz/RedHat.py) to return:
(56, 'SSL read: errno -12192')
> # man curl
> 56 Failure in receiving network data.
If conductor (imagefactory/oz) ever reports that it is "Unable to route to the repo host from here, and SSH tunnel will never be established", check the curl return code which will be shortly after this message. If it matches, please re-open this bug report.
As Ian suggested, I suspect the fault lies with the repo host (katello in this case). Since I've been unable to recreate the failure, I cannot determine the root cause.
|