Bug 1222155
| Summary: | RHEL OSP provider passes credentials but fails to refresh environment info | ||
|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | Brett Thurber <bthurber> |
| Component: | Providers | Assignee: | Ladislav Smola <lsmola> |
| Status: | CLOSED ERRATA | QA Contact: | Pete Savage <psavage> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | unspecified | CC: | dclarizi, gblomqui, jfrey, jhardy, jmarc, lsmola, obarenbo, psavage, sdodson |
| Target Milestone: | GA | ||
| Target Release: | 5.5.0 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 5.5.0.1 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-12-08 13:09:42 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Brett Thurber
2015-05-15 22:16:06 UTC
I spoke with bthurber on IRC about this, and it seems that fog is trying to connect to an internal IP for one of the services (192.168.x.x for glance in this case), instead of the public IP (10.19.x.x). That pastebin is from my personal machine trying to hit his servers and failing in the exact same way. (In reply to Jason Frey from comment #2) > I spoke with bthurber on IRC about this, and it seems that fog is trying to > connect to an internal IP for one of the services (192.168.x.x for glance in > this case), instead of the public IP (10.19.x.x). That pastebin is from my > personal machine trying to hit his servers and failing in the exact same way. Pastebin please? It's in the OP. (listed as Debug info: http://pastebin.test.redhat.com/283668 ) snippet from Brett's appliance's evm.log [----] I, [2015-05-19T16:37:29.495877 #54564:5afe9c] INFO -- : MIQ(EmsRefresh::Refreshers::OpenstackRefresher.refresh) EMS: [rhci-rhelosp], id: [7] Refreshing targets for EMS: [rhci-rhelosp], id: [7]... [----] I, [2015-05-19T16:37:29.495928 #54564:5afe9c] INFO -- : MIQ(EmsRefresh::Refreshers::OpenstackRefresher.refresh) EMS: [rhci-rhelosp], id: [7] EmsOpenstack [rhci-rhelosp] id [7] [----] I, [2015-05-19T16:37:43.361230 #6679:d31ea4] INFO -- : MIQ(EmsOpenstack.with_provider_connection) Connecting through EmsOpenstack: [rhci-rhelosp] [----] I, [2015-05-19T16:37:58.362254 #6679:d31ea4] INFO -- : MIQ(EmsOpenstack.with_provider_connection) Connecting through EmsOpenstack: [rhci-rhelosp] [----] I, [2015-05-19T16:38:13.363210 #6679:d31ea4] INFO -- : MIQ(EmsOpenstack.with_provider_connection) Connecting through EmsOpenstack: [rhci-rhelosp] [----] I, [2015-05-19T16:38:28.372424 #6679:d31ea4] INFO -- : MIQ(EmsOpenstack.with_provider_connection) Connecting through EmsOpenstack: [rhci-rhelosp] [----] E, [2015-05-19T16:38:30.285836 #54564:5afe9c] ERROR -- : MIQ(EmsRefresh::Refreshers::OpenstackRefresher.refresh) EMS: [rhci-rhelosp], id: [7] Refresh failed [----] E, [2015-05-19T16:38:30.286075 #54564:5afe9c] ERROR -- : MIQ(EmsRefresh::Refreshers::OpenstackRefresher.refresh) EMS: [rhci-rhelosp], id: [7] Unable to perform refresh for the following targets: [----] E, [2015-05-19T16:38:30.286186 #54564:5afe9c] ERROR -- : --- EmsOpenstack [rhci-rhelosp] id [7] My guess is that it's actually trying to hit the adminURL and not the internalURL. Note that OpenStack actually has three endpoints per service: publicURL, internalURL, and adminURL. We can check the fog source code to see if it is actually hitting the adminURL for glance in some cases. Also, we need to check the openstack documentation on what IP should be used for the adminURL. But, I know we talk to the Keystone adminURL when accessing token data. So, I would suspect that the adminURL needs to be on a public IP. @greg it's all solved http://talk.manageiq.org/t/solved-problem-with-new-ems-cloud/806/19 master fix for one of the problems is here https://github.com/ManageIQ/manageiq/pull/3606 should I backport it for 5.4.z as part of this BZ? If not we can close this. I tried but, I'm failing to create a sec group with no description, unless I go in and manually alter the database, both rhos5 and rhos6 do not allow me to create a sec group without entering a description. Any ideas? @Pete using my env builder script I can create create sec group with description "", nil and omitting it entirely. Tested on rhos7. You are probably blocked by CLI here? Since it's optional in API I'll enhance the automated tests with this later, then we will see if it fails on some version of RHOS :-) Verified in 5.5.0.7 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2015:2551 |