Bug 1252413

Summary: 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)>
Product: Red Hat CloudForms Management Engine Reporter: Nandini Chandra <nachandr>
Component: ProvidersAssignee: Greg Blomquist <gblomqui>
Status: CLOSED DUPLICATE QA Contact: Dave Johnson <dajohnso>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.4.0CC: asimonel, fdewaley, gblomqui, jfrey, jhardy, jocarter, juhu, lsmola, mcornea, nachandr, obarenbo
Target Milestone: GA   
Target Release: 5.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-03 11:28:03 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 Nandini Chandra 2015-08-11 10:54:10 UTC
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 11:53:16 UTC
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 12:42:05 UTC
I've got the same issue with an OSP director based install. Does CFME require SSL endpoints?

Comment 9 August Simonelli 2015-08-20 00:15:09 UTC
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 07:59:29 UTC
@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 13:41:37 UTC
@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 14:39:00 UTC
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 14:57:20 UTC
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 13:34:28 UTC
@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 13:38:15 UTC
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 13:45:35 UTC
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 11:28:03 UTC

*** This bug has been marked as a duplicate of bug 1272041 ***

Comment 18 Jun Hu 2015-11-26 02:31:28 UTC
(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.