On 07/26/2013 01:59 PM, Jonathan Proulx wrote:
On Fri, Jul 26, 2013 at 1:01 PM, Jay Pipes <jaypi...@gmail.com <mailto:jaypi...@gmail.com>> wrote:On 07/25/2013 08:24 PM, Joshua Harlow wrote: You mean process/forking API right? Honestly I'd sort of think the whole limits.py that is this rate-limiting could also be turned off by default (or a log warn message occurs) when multi-process nova-api is used since the control for that paste module actually returns the currently enforced limits (and how much remaining) and on repeated calls to different processes those values will actually be different . This adds to the confusion that this rate-limiting in-memory/process solution creates which does also seem bad. https://github.com/openstack/__nova/blob/master/nova/api/__openstack/compute/limits.py <https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/limits.py> Maybe we should not have that code in nova in the future, idk Agreed +10. Like using SSL in the Python daemons, it doesn't belong in a production Nova deployment. This kind of thing is more appropriate to handle in some external terminator, IMO Strongly disagree about SSL. Anything that talks on the network should be able to do so securely. It is valid to want to abstract that away for someone else to deal with but if that is the case it should be done explicitly, like writing WSGI apps and requiring a server to do network communications.
? I think you're missing my point... I was saying that having the Python daemons themselves terminate the SSL is a bad idea for scaling and performance reasons, not that using SSL is a bad practice. :)
The SSL configurations options for Nova/Glance/Cinder/Neutron should only be used in development/testing.
-jay _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
