mount flag to log to stdout to be provided

[raghavendra-talur]

By default the current gluster plugin in kubernetes and openshift log in /var/log/openshift etc. We should provide capability to change log file and/or provide a way to show them on stdout.

[JohnStrunk]

Looking at this from the end-user perspective, could we phrase this as:

As a system administrator, I want the log output from the Gluster fuse mounts to be available in my centralized logging DB so that I can easily debug problems with pods that use gluster-backed PVs.

From an implementation perspective, yes, sending logs to stdout and having that picked up by the logging infrastructure seems to be the way to go. Some issues to consider:

• Today, each mount gets its own log file, making it easy to tell mounts apart
• With CSI, the mount tools will be containerized, causing all mounts on a host to originate from a single pod. What would be a good approach to ensure separate (or separable) log streams per mount (as we have today)?
• Do we need to do anything to make the correlation with the node, pod, pvc, and pv easier for the admin? (i.e., What steps do we need to take to ensure the admin doesn't need to chase down a bunch of other logs and uuids in order to find the right glusterfs log stream?)

[humblec]

@raghavendra-talur for above defined requirements (for mentioning the log file and to provide a way to show them on stdout) do we already have fuse mount options in gluster ? iic, its already available, but I need to confirm.

[amarts]

Yes, you have an option to make log file as '/dev/stdout'.

mount -t glusterfs -olog-file=/dev/stdout $host:$volname /mount/point

[humblec]

Thanks @amarts for confirming the /dev/stdout mechanism. I share almost same thoughts what @JohnStrunk brought up, the current design of separation of log file is done based on the container use case. That said, there can be 100s of volumes and different pods using these volumes, having a log file based on pvc and pod name is the current mechanism which allows admin to track the logs in a better way. At the same time I see a value of pushing logs to /dev/stdout as well, so we can bring this option as well. One thing which I am not that sure is the difficulty of capturing logs on a single file for 100s of volumes created in a setup. But, if admin want that, I am fine to provide it.