Open Stack

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?


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.

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.

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).

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