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