cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rene Moser <m...@renemoser.net>
Subject Re: represent the object in the logs
Date Wed, 12 Apr 2017 21:52:44 GMT
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é

Mime
View raw message