Open Stack

On 05/02/2014 03:06 PM, Rob Crittenden wrote:
> TL;DR
>
> Work is happening on a unified client library. This provides the 
> opportunity to rework the way SSL options are handled. Can we discuss 
> this in one of the sessions at the Atlanta Summit in a few weeks?
>
>

Good survey, thanks.

> https://blueprints.launchpad.net/oslo/+spec/common-client-library-2 
> outlines a path to a common client library in OpenStack. It is still a 
> work-in-progress though most projects have some amount included 
> already in openstack/common/apiclient
>
> If you have some time and aren't familiar with this project, this 
> thread will bring you up to speed: 
> http://lists.openstack.org/pipermail/openstack-dev/2014-January/024441.html
>
> Parallel to this effort was 
> https://wiki.openstack.org/wiki/SecureClientConnections which outlined 
> an effort to replace httplib{2} with requests which is mostly complete 
> with the exception of neutronclient and glanceclient which still use 
> httplib.
>
> I'm trying to get devstack to the point where it can configure all the 
> services with SSL so it can be be part of the acceptance process. This 
> is for client communication, there is no expectation that anyone would 
> deploy native SSL endpoints. For the most part things just work. Most 
> of the issues I've run into are server to server communication 
> relating to passing in the CA certificate path.
>
> This leads to two interrelated questions:
>
> 1. Given the common client, how much should be done in the interim to 
> clean things up?
> 2. How will configuration options be handled for server to server 
> communication?
>
> Right now each project has its own local copy of the common client but 
> only exceptions are being used. Is there any guess on how soon the 
> common HTTP client can be in place? This may drive how much effort is 
> expended trying to clean up the existing client code.
>
> There are significant, probably well-known differences between the 
> clients, and in the options available to clients used within several 
> servers to communicate as clients to other servers (e.g. nova to glance).
>
> Here is a brief taste of what I'm talking about:
>
> heatclient defines get_system_ca_file() which will use the system 
> bundle as a fallback. It is the only client project that does this.
I like this.  We should probably use it in Keystone.

>
> Heat seems to have the most expansive set of configuration options, 
> providing a global clients section and service-specific 
> clients_<service> set of options. See 
> https://github.com/openstack/heat/blob/master/etc/heat/heat.conf.sample#L589 
> . It was suggested that this be considered for nova as well.
Not surprised they have the best perspective, since they talk to just 
about every other service.

>
> The nova team is working to consolidate the available CA options into 
> a single one in https://bugs.launchpad.net/nova/+bug/1299841 but 
> leaves behind the separate options for insecure connections.
>
> Disabling SSL compression is important to swift and glance and their 
> clients provide a way to disable it, and each server that calls these 
> typically have configuration options to manage it (why there are even 
> options is unclear since the glance and swift server teams really want 
> this disabled).
>
Did swift leave this behind when they switched to Requests?


> How SSL is handled in the configuration files is separate from the 
> Common Client blueprint. Will there continue to be separate options 
> for insecure, ssl_compression and ca_certificates or will there be a 
> single, common option set somewhere, or a mixed bag?
>
> How flexible do the CA certificates need to be? Given the distributed 
> nature of OpenStack, and the fact that some endpoints may be internal 
> and others external facing, it might seem reasonable to have separate 
> options for each service. It is also confusing and repetitive. The 
> heatclient get_system_ca_file() seems to be the way to go, along with 
> an override in the service configuration file.
>
> That doesn't really handle compression or insecure though, which still 
> probably need to be per-service.
>
> I think the heat/heatclient approach is the best, coupled with good 
> defaults in the common client. I think it should look like:
>
> Common client:
>  ca_certificates = get_system_ca_file()
>  insecure = False
>  ssl_compression = False
>
> Ideally the system CA is configured correctly so there is nothing to 
> do in the client except pass in a https endpoint.
>
> Each server uses the heat method and defines:
>
>  [ client ] (most likely always empty)
>
>  [ client_<service> ]
>
> I see are three possible options
>
>   ca_certificates_file = /path/to/file
>   insecure = Boolean
>   ssl_compression = Boolean
>
>
> This is the most flexible setup but how one documents it without 
> confusing people I'm not entirely sure. I think the sample 
> configuration files should have the entire sections commented out, and 
> heavily, that these are for overrides only, and only when needed.
>
> Backwards compatibility will be an issue, though the old options can 
> be deprecated and eventually removed. Or a script can probably be used 
> to migrate options to the new format.


>
> rob
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev