Bug 1252413 - Adding RHOS provider throws <Fog> excon.error #<Excon::Errors::SocketError: SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: unknown protocol (OpenSSL::SSL::SSLError)>
Adding RHOS provider throws <Fog> excon.error #<Excon::Errors::SocketError: S...
Status: CLOSED DUPLICATE of bug 1272041
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers (Show other bugs)
5.4.0
Unspecified Unspecified
medium Severity medium
: GA
: 5.5.0
Assigned To: Greg Blomquist
Dave Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-11 06:54 EDT by Nandini Chandra
Modified: 2015-11-25 21:31 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-03 06:28:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nandini Chandra 2015-08-11 06:54:10 EDT
Description of problem:
------------------------
The following error is logged in evm.log after adding a RHOS provider to CFME.

<Fog> excon.error #<Excon::Errors::SocketError: SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: unknown protocol (OpenSSL::SSL::SSLError)>


Version-Release number of selected component (if applicable):
---------------------------
5.4.1


How reproducible:
-----------------
Always


Steps to Reproduce:
-------------------
1.Add a RHOS provider to CFME


Actual results:
---------------
Validation succeeds, fog error is logged to evm.log and fog.log.


Expected results:
-----------------
No errors


Additional info:
----------------
Comment 2 Nandini Chandra 2015-08-11 07:53:16 EDT
Snippet from evm.log:

[----] I, [2015-08-11T04:03:57.205324 #2903:54dea4]  INFO -- : MIQ(Authentication.validation_successful) [ExtManagementSystem] [2], previously valid/invalid on: [2015-08-11 06:55:49 UTC]/[], previous status: [Valid]
[----] E, [2015-08-11T04:03:57.213951 #15138:959ea8] ERROR -- : <Fog> excon.error     #<Excon::Errors::SocketError: SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: unknown protocol (OpenSSL::SSL::SSLError)>

[----] I, [2015-08-11T04:03:57.229610 #2903:54dea4]  INFO -- : MIQ(MiqQueue.put)        Message id: [107697],  id: [], Zone: [default], Role: [], Server: [], Ident: [generic], Target id: [], Instance id: [], Task id: [], Command: [MiqEvent.raise_evm_event], Timeout: [600], Priority: [100], State: [ready], Deliver On: [], Data: [], Args: [["EmsVmware", 2], "ems_auth_valid", {}]
[----] I, [2015-08-11T04:03:57.229984 #2903:54dea4]  INFO -- : MIQ(MiqQueue.delivered)  Message id: [107693], State: [ok], Delivered in [0.382563786] seconds
[----] E, [2015-08-11T04:03:57.750472 #15138:959ea8] ERROR -- : <Fog> excon.error     #<Excon::Errors::SocketError: SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: unknown protocol (OpenSSL::SSL::SSLError)>

[----] E, [2015-08-11T04:03:58.079763 #15138:959ea8] ERROR -- : <Fog> excon.error     #<Excon::Errors::SocketError: SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: unknown protocol (OpenSSL::SSL::SSLError)>
Comment 6 August Simonelli 2015-08-19 08:42:05 EDT
I've got the same issue with an OSP director based install. Does CFME require SSL endpoints?
Comment 9 August Simonelli 2015-08-19 20:15:09 EDT
ok i see, my connect error is coming from cfme trying to hit glance on an internal endpoint. but my internal endpoint for glance is on a network (storage) that is not accessible to cfme. essentially it seems all networks that may host an admin or internal or public url need to be accessible to cfme. this seems a potential security issue to have this box bridging all these networks. would be great to be able to manage the endpoints with more granularity. for instance, i have glance available on an external endpoint why can't cfme use it? instead it tries its adminurl, which is on a storage network and not really where cfme should be located.
Comment 10 Ladislav Smola 2015-08-20 03:59:29 EDT
@greg the fix for the Socket error would be making users choose SLL/NO SSL in provider form? Otherwise we can't do anything, the it's being logged inside excon gem.

@august not sure tbh, I think now we are just getting default urls for the Admin user. Which is being done by Fog I think. Please talk to Greg and John Hardy, whether it's a reasonable RFE, or we expect CFME to access everything. 

Do you have this URL accessible to Horizon? Or, how is it handled there?
Comment 11 Greg Blomquist 2015-08-20 09:41:37 EDT
@ladas, yeah ... that's a feature that's still in the future.  We have some other dependencies that need to be solved first before we introduce the ability to select ssl/non-ssl in the UI, unfortunately.

@august, it might be possible to tune how we're using the Fog library (which is the Ruby library we use to communicate with OpenStack).  We can add research into something like that to our development schedule to at least see if it's possible.
Comment 12 August Simonelli 2015-08-20 10:39:00 EDT
I've seen an option documented to adjust (but have't tried it) by modifying /var/www/miq/lib/openstack/openstack_handle/handle.rb with :openstack_endpoint_type => 'publicURL',

any investigation you can do would be cool - but it's certainly not an urgent issue :-)
Comment 13 Ladislav Smola 2015-08-20 10:57:20 EDT
hm not sure why you even have there internal url, by default it should be public

https://github.com/fog/fog/blob/e28a76c9036cd85c29224d9d1ea2938619d996b9/lib/fog/openstack/core.rb#L211

and I don't see that CFME is setting it to internal anywhere
Comment 14 Greg Blomquist 2015-08-27 09:34:28 EDT
@august, @ladas, I don't think the endpoint is internal, per se.  I think it's an admin endpoint that happens to be configured as an internal IP (192.168...).

Also, a grep of the fog code shows the different default endpoint types in use:

> $ grep -Ir "endpoint_type.*||" .                                                                                                                                                                                   
> ./orchestration.rb:          @openstack_endpoint_type = options[:openstack_endpoint_type] || 'publicURL'
> ./volume.rb:          @openstack_endpoint_type        = options[:openstack_endpoint_type] || 'adminURL'
> ./metering.rb:          @openstack_endpoint_type        = options[:openstack_endpoint_type] || 'adminURL'
> ./storage.rb:          @openstack_endpoint_type = options[:openstack_endpoint_type] || 'publicURL'
> ./planning.rb:          @openstack_endpoint_type        = options[:openstack_endpoint_type] || 'adminURL'
> ./identity_v2.rb:            @openstack_endpoint_type = options[:openstack_endpoint_type] || 'adminURL'
> ./identity_v3.rb:            @openstack_endpoint_type = options[:openstack_endpoint_type] || 'adminURL'
> ./core.rb:        @openstack_endpoint_type = options[:openstack_endpoint_type] || 'publicURL'
> ./core.rb:      endpoint_type         = (options[:openstack_endpoint_type] || 'publicURL').to_s
> ./core.rb:      endpoint_type         = map_endpoint_type(options[:openstack_endpoint_type] || 'publicURL')
> ./image.rb:          @openstack_endpoint_type        = options[:openstack_endpoint_type] || 'adminURL'
> ./baremetal.rb:          @openstack_endpoint_type        = options[:openstack_endpoint_type] || 'adminURL'

So, the volume, metering, planning, identity_v2, identity_v3, image, and baremetal services all have places where they will default to using the adminURL endpoint.
Comment 15 Greg Blomquist 2015-08-27 09:38:15 EDT
Also, I'm going to open this as a separate bug.

The original bug here is that when connecting to OpenStack with a non-SSL connection, CFME logs an error saying that trying to connect over SSL failed.  It's largely a non-bug and is getting logged by Excon (so we're unable to trap it).  But, a possible fix is to allow the CFME admin to select whether the current connection to OpenStack is SSL or non-SSL.  Then the guesswork in CFME is removed.
Comment 16 Greg Blomquist 2015-08-27 09:45:35 EDT
I opened bug #1257629 to track further discussions related to the publicURL vs. adminURL OpenStack service endpoints.  Please make all future comments there.
Comment 17 Ladislav Smola 2015-11-03 06:28:03 EST

*** This bug has been marked as a duplicate of bug 1272041 ***
Comment 18 Jun Hu 2015-11-25 21:31:28 EST
(In reply to August Simonelli from comment #12)
> I've seen an option documented to adjust (but have't tried it) by modifying
> /var/www/miq/lib/openstack/openstack_handle/handle.rb with
> :openstack_endpoint_type => 'publicURL',
> 
> any investigation you can do would be cool - but it's certainly not an
> urgent issue :-)

yes, it is a true workaround, thanks for helping me.

Note You need to log in before you can comment on or make changes to this bug.