#Logging Practices inside Trident Storage Drivers

1 messages · Page 1 of 1 (latest)

vast crane
#

Hello,

We've been poking around the storage drivers and noticed something a bit confusing with the logging. It looks like Logc() is being used in places like storage_drivers/common.go (and we saw it mentioned in
azure_anf.go too for example), even though the
logger.go file says it's not supposed to be used by storage drivers.

The tricky part is, when Logc() spits out debug messages, we end up having to enable both the main debug flag for Trident pods and the debugTraceFlag for the backend to get all the driver-related debug info. It makes debugging a bit more of a hassle than we expected.

Could you please clarify the intended logging strategy for storage drivers, specifically regarding the use of Logc() versus Logd()? Is the current usage of Logc() in storage drivers for debug messages the intended behavior , and if so, how does it align with the stated guidelines and the distinct purposes of the debug and debugTraceFlag?

Thank you 🙂

sly berry
#

"debugTraceFlags" are an older mechanism that allows for logging driver function entry points as well as all storage API payloads. Most of Trident code uses Logc(), but driver logging functions, especially those that log driver entry points should use Logd() so that the flags are honored.