Open Stack

On 24 October 2013 08:28, John Griffith <john.griffith at solidfire.com> wrote:
> So I touched on this a bit in my earlier post but want to reiterate here and
> maybe clarify a bit.  I agree that cleaning up and standardizing the logs is
> a good thing, and particularly removing unhandled exception messages would
> be good.  What concerns me however is the approach being taken here of
> saying things like "Error level messages are banned from Tempest runs".
>
> The case I mentioned earlier of the negative test is a perfect example.
> There's no way for Cinder (or any other service) to know the difference
> between the end user specifying/requesting a non-existent volume and a valid
> volume being requested that for some reason can't be found.  I'm not quite
> sure how you place a definitive rule like "no error messages in logs" unless
> you make your tests such that you never run negative tests?

Let me check that I understand: you want to check that when a user
asks for a volume that doesn't exist, they don't get it, *and* that
the reason they didn't get it was due to Cinder detecting it's
missing, not due to e.g. cinder throwing an error and returning 500 ?

If so, that seems pretty straight forward; a) check the error that is
reported (it should be a 404 and contain an explanation which we can
check) and b) check the logs to see that nothing was logged (because a
server fault would be logged).

> There are other cases in cinder as well that I'm concerned about.  One
> example is iscsi target creation, there are a number of scenarios where this
> can fail under certain conditions.  In most of these cases we now have retry
> mechanisms or alternate implementations to complete the task.  The fact is
> however that a call somewhere in the system failed, this should be something
> in my opinion that stands out in the logs.  Maybe this particular case would
> be well suited to being a warning other than an error, and that's fine.  My
> point however though is that I think some thought needs to go into this
> before making blanketing rules and especially gating criteria that says "no
> error messages in logs".

I agree thought and care is needed. As a deployer my concern is that
the only time ERROR is logged in the logs is when something is wrong
with the infrastructure (rather than a user asking for something
stupid). I think my concern and yours can both be handled at the same
time.


-Rob


---
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud