Red Hat Bugzilla – Bug 1222155
RHEL OSP provider passes credentials but fails to refresh environment info
Last modified: 2015-12-08 08:09:42 EST
Description of problem: Adding a new RHEL OSP cloud provider (RHEL OSP 6), passes credential check and successfully adds. When refreshing relationships and power states, timeout occurs. Version-Release number of selected component (if applicable): 5.4.0.0.25.20150429111523_0455f87 How reproducible: Everytime Steps to Reproduce: 1. Navigate to Cloud > Providers 2. Add a new Openstack provider 3. Once added, refresh relationships and power states Actual results: Timeout when fleecing OpenStack environment for status. Expected results: Environment refresh completes successfuly and objects are reported correctly. Additional info: Debug info: http://pastebin.test.redhat.com/283668 RHEL OSP environment config: 3 networks - Provisioning (pxe, tenant, admin api, management, cluster management, storage, storage clustering) - External (external) - Public (public api) <---this is what CFME is connecting to for management RHEL OSP mapped endpoints: http://pastebin.test.redhat.com/283665
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