On 11/15/2015 03:13 PM, Clint Byrum wrote:
Excerpts from Xav Paice's message of 2015-11-15 11:45:55 -0800:
After having a brief discussion this morning (NZ time) on the
#python-requests irc, it seems that using the system CA bundle is a "Not a
chance" situation. They've tried, and found it unmaintainable due to the
vast variations between system layouts (multiple OS, not just multiple
distro). I can see their point.
Somehow we got all the distros and unices to agree where timezone, hosts,
etc. go. Perhaps it's time we form a group to get a single place. I
commend the requests authors for trying, and think this is something
that must affect other languages as well.
Others have mentioned env vars not working particularly well either - which
really leaves a config option and that is something that ops/deployers can
tailor to suit their particular system without either the requests people
nor the OpenStack people having to maintain.
Config option is fine. But I wonder if we could also just write a
wrapper that understands the distros we support, and picks the system
level one. There are, what, 2 schemes to support? 3?
We already wrap requests.Session in keystoneauth.
We already have options to keystoneauth1.session.Session to tell it
where the cacert, cert and key are.
Both of those are done and are everywhere. SO - potential tasks:
1) add ability to specify cert/cacert/key parameters in config files for
places where we're configuring one service's connections to another service
2) maybe work the default behavior of keystoneauth1.session.Session to
detect which OS it's on and set the default values such that system CA
bundles are used.
Of course, this is all predicated on getting everything on keystoneauth
- but that's a current TODO-list item anyway.
Once we do that, 1 actually becomes easier - because keystoneauth
already has: keystoneauth1.loading.register_session_conf_options(),
which adds all the appropriate Session conf parameters to a given
oslo.config CONF object.
Monty
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
