Open Stack

Now in my understanding our services does not log to user. The user gets whatever error message/exception it happens to be thrown at. This is exactly Why we need some common identifier between them (and who ever offers request ID being that, I can get some of my friends with well broken English calling you and trying to give that to you over phone ;) ).

More inline.

> -----Original Message-----
> From: Rochelle Grober [mailto:rochelle.grober at huawei.com]
> Sent: 02 February 2015 21:34
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Product] [all][log] Openstack HTTP error codes
> 
> 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.

NO! Absolutely not. This is where we need to be careful what we classify as DEBUG and what INFO+ as the ops definitely do not need nor want it all. 
> 
> 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.

They see pretty much just the error messages raised to them, not the cloud infra logs anyways. What we need to do is to be more helpful towards them what they should and can help themselves with and where they would need ops help.
> 
> So, sounds like a security policy issue of what makes it to tenant logs and
> what stays "in the data center" thing.

Logs should never contain sensitive information (URIs, credentials, etc.) regardless where they are stored. Again obscurity is not security either.
> 
> 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.

We need guidelines. Now it's really hard to come by with tight rules how things needs to be logged as backend failure can be critical for some services while others might not care too much about that. (For example if swift has disk down, it's not catastrophic failure, they just move to next copy. But if back end store is down for glance, we can do pretty much nothing. Now should these two back end store failures be logged same way, no they should not.)

We need to keep the decision in the projects as mostly they are the only ones knowing how specific error condition affects the service. Also if the rules does not fit, it's really difficult to enforce for those, so let's not pick that fight.

- Erno
> 
> --Rocky
> 
> (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
> 
> --
> Sean Dague
> http://dague.net
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev