Open Stack

On 07/26/2013 01:59 PM, Jonathan Proulx wrote:
> On Fri, Jul 26, 2013 at 1:01 PM, Jay Pipes <jaypipes at gmail.com
> <mailto:jaypipes at 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