Hi Rafael On 04/12/2017 08:27 PM, Rafael Weingärtner wrote: > Well, I think the missing point to understand why we have these different > situations is the understanding of the developer’s mind. It is so diverse > and unique from people to people, and because we do not have a policy on > that, each developer is doing the best they know and think.
I should not have asked "why". I know why, nobody is perfect :) That is fine. I just wondered if there is something I've been missing (I am also not perfect and I know :P). > For instance, at first sight, the idea of calling the “toString” of an > object to append its information in a log entry might be interesting. > However, objects like the “VmInstance” are quite big and would probably > clutter the log entry. So, logs are getting big, we must handle logs anyway. I have no problem with big logs. I like big logs, big logs are detailed, bigger logs are more detailed. > In my opinion, for most log entries at the DEBUG/INFO/WARN levels the ID of > the logged element should be more than enough to the > operators/administrators to track down events or problems in the cloud. I kind of disagree here for 2 technical reasons: The ID of the record (ID NOT UUID) is not unique, (think about upgrade/rollback scenarios, the id will probably be identical but the resource would not be the same). The ID is only used "internally" for relation mapping, there is not reason to show this ID to a user/admin as a user will not be able to query a VM by its ID, but UUID. I would like to see at least (only?) the UUID for an resource being logged, as it is the external, unique identifier for an resource. > Others probably think the opposite, meaning that, only the ID is not enough > and more details about the object in an event are required. In the absence > of a policy to regulate this, both are valid arguments under different > perspectives. Other thoughts anyone? Kind Regards René
