On 24 October 2013 08:28, John Griffith <john.griff...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev