This sounds like something we can bake into the session object to make it 
easier / more consistent. 
--Morgan

Sent via mobile

> On Mar 25, 2015, at 14:03, John Dewey <j...@dewey.ws> wrote:
> 
> I faced this very issue in the past.  We solved the problem by adding the CA 
> to the system bundle (as you stated).  We also ran into problems where python 
> would still not validate the CA.  However, this turned out to be a 
> permissions error with cacerts.txt[1] when httplib2 was installed through 
> pip.  Nowadays openstack uses requests which I don’t believe utilizes 
> httplib2.
> 
> [1] https://code.google.com/p/httplib2/issues/detail?id=292&q=certificate
>> On Wednesday, March 25, 2015 at 11:13 AM, Jesse Keating wrote:
>> 
>> We're facing a bit of a frustration. In some of our environments, we're 
>> using a self-signed certificate for our ssl termination (haproxy). We have 
>> our various services pointing at the haproxy for service cross-talk, such as 
>> nova to neutron or nova to glance or nova to cinder or neutron to nova or 
>> cinder to glance or all the things to keystone. When using a self-signed 
>> certificate, these services have trouble validating the cert when they 
>> attempt to talk to each other. This problem can be solved in a few ways, 
>> such as adding the CA to the system bundle (of your platform has such a 
>> thing), adding the CA to the bundle python requests uses (because 
>> hilariously it doesn't always use the system bundle), or the more direct way 
>> of telling nova, neutron, et al the direct path to the CA file.
>> 
>> This last choice is the way we went forward, more explicit, and didn't 
>> depend on knowledge if python-requests was using its own bundle or the 
>> operating system's bundle. To configure this there are a few places that 
>> need to be touched.
>> 
>> nova.conf:
>> [keystone_authtoken]
>> cafile = <path>
>> 
>> [neutron]
>> ca_certificates_file = <path>
>> 
>> [cinder]
>> ca_certificates_file = <path>
>> 
>> (nothing for glance hilariously)
>> 
>> 
>> neutron.conf
>> [DEFAULT]
>> nova_ca_certificates_file = <path>
>> 
>> [keystone_authtoken]
>> cafile = <path>
>> 
>> glance-api.conf and glance-registry.conf
>> [keystone_authtoken]
>> cafile = <path>
>> 
>> cinder.conf
>> [DEFAULT]
>> glance_ca_certificates_file = <path>
>> 
>> [keystone_authtoken]
>> cafile = <path>
>> 
>> heat.conf
>> [clients]
>> ca_file = <path>
>> 
>> [clients_<whatever>]
>> ca_file = <path>
>> 
>> 
>> As you can see, there are a lot of places where one would have to define the 
>> path, and the frustrating part is that the config name and section varies 
>> across the services. Does anybody think this is a good thing? Can anybody 
>> think of a good way forward to come to some sort of agreement on config 
>> names? It does seem like heat is a winner here, it has a default that can be 
>> defined for all clients, and then each client could potentially point to a 
>> different path, but every config entry is named the same. Can we do that 
>> across all the other services?
>> 
>> I chatted a bit on twitter last night with some nova folks, they suggested 
>> starting a thread here on ops list and potentially turning it into a hallway 
>> session or real session at the Vancouver design summit (which operators are 
>> officially part of).
>> 
>> - jlk
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Reply via email to