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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
