[Openstack-operators] [openstack-dev] [Product] [all][log] Openstack HTTP error codes

Rochelle Grober rochelle.grober at huawei.com
Mon Feb 2 21:34:12 UTC 2015

What I see in this conversation is that we are talking about multiple different user classes.

Infra-operator needs as much info as possible, so if it is a vendor driver that is erring out, the dev-ops can see it in the log.

Tenant-operator is a totally different class of user.  These guys need VM based logs and virtual network based logs, etc., but should never see as far under the covers as the infra-ops *has* to see.

So, sounds like a security policy issue of what makes it to tenant logs and what stays "in the data center" thing.  

There are *lots* of logs that are being generated.  It sounds like we need standards on what goes into which logs along with error codes, logging/reporting levels, criticality, etc.


(bcc'ing the ops list so they can join this discussion, here)

-----Original Message-----
From: Sean Dague [mailto:sean at dague.net] 
Sent: Monday, February 02, 2015 8:19 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Product] [all][log] Openstack HTTP error codes

On 02/01/2015 06:20 PM, Morgan Fainberg wrote:
> Putting on my "sorry-but-it-is-my-job-to-get-in-your-way" hat (aka security), let's be careful how generous we are with the user and data we hand back. It should give enough information to be useful but no more. I don't want to see us opened to weird attack vectors because we're exposing internal state too generously. 
> In short let's aim for a slow roll of extra info in, and evaluate each data point we expose (about a failure) before we do so. Knowing more about a failure is important for our users. Allowing easy access to information that could be used to attack / increase impact of a DOS could be bad. 
> I think we can do it but it is important to not swing the pendulum too far the other direction too fast (give too much info all of a sudden). 

Security by cloud obscurity?

I agree we should evaluate information sharing with security in mind.
However, the black boxing level we have today is bad for OpenStack. At a
certain point once you've added so many belts and suspenders, you can no
longer walk normally any more.

Anyway, lets stop having this discussion in abstract and actually just
evaluate the cases in question that come up.


Sean Dague

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-operators mailing list