cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Weingärtner <>
Subject Re: represent the object in the logs
Date Wed, 12 Apr 2017 18:27:43 GMT
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.

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.

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.
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

On Wed, Apr 12, 2017 at 11:49 AM, Rene Moser <> wrote:

> Hi
> In logs we see all kind variations how an object is printed to the
> users. E.g. for VMs we have seen, the DB ID, UUID, internal name, name
> etc. in different debug log messages. And this makes debugging harder
> than it should.
> I wondered, why don't we just use the "toString()" in VO classes.
> E.g in this PR
> ab243638abf88707693d464b3b1836feR1503
> We see a:
> s_logger.debug("Host is in PrepareForMaintenance state - Stop VM
> operation on the VM id: " + vm.getId() + " is not allowed");
> With a toString in the VO class of the VM this would turn into
> s_logger.debug("Host is in PrepareForMaintenance state - Stop VM
> operation on the VM: " + vm + " is not allowed");
> Did I miss anything?
> René

Rafael Weingärtner

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message