Fedora Account System
Red Hat Associate
Red Hat Customer
Created attachment 1537106 [details] /var/log/glusterfs/glusterd.log excerpt Description of problem: Gluster starts pushing logs every minute into /var/log/glusterfs/bricks/ and /var/log/glusterfs/glusterd.log when cluster containing some volumes is imported into RHGSWA. Version-Release number of selected component (if applicable): glusterfs-3.12.2-43.el7rhgs.x86_64 glusterfs-api-3.12.2-43.el7rhgs.x86_64 glusterfs-cli-3.12.2-43.el7rhgs.x86_64 glusterfs-client-xlators-3.12.2-43.el7rhgs.x86_64 glusterfs-events-3.12.2-43.el7rhgs.x86_64 glusterfs-fuse-3.12.2-43.el7rhgs.x86_64 glusterfs-geo-replication-3.12.2-43.el7rhgs.x86_64 glusterfs-libs-3.12.2-43.el7rhgs.x86_64 glusterfs-rdma-3.12.2-43.el7rhgs.x86_64 glusterfs-server-3.12.2-43.el7rhgs.x86_64 gluster-nagios-addons-0.2.10-2.el7rhgs.x86_64 gluster-nagios-common-0.2.4-1.el7rhgs.noarch tendrl-gluster-integration-1.6.3-14.el7rhgs.noarch tendrl-node-agent-1.6.3-17.el7rhgs.noarch How reproducible: 90% Steps to Reproduce: 1. Create gluster cluster with 6 nodes and some volumes (I used volume_beta_arbiter_2_plus_1x2 and volume_gama_disperse_4_plus_2x2) 2. Install tendrl. 3. Import cluster into Tendrl. 4. Monitor /var/log/glusterfs/glusterd.log and /var/log/glusterfs/bricks/ logs. Actual results: Every minute are pushed logs into /var/log/glusterfs/bricks/ and /var/log/glusterfs/glusterd.log. Excerpts that are pushed are in attachments to this bz. Expected results: There shouldn't be any error or redundant logs when cluster is imported into RHGSWA. Additional info: Based on https://bugzilla.redhat.com/show_bug.cgi?id=1561392#c19
Created attachment 1537107 [details] /var/log/glusterfs/bricks/mnt-brick_beta_arbiter_1-1.log excerpt
"Gluster starts pushing logs every minute into /var/log/glusterfs/bricks/ and /var/log/glusterfs/glusterd.log when cluster containing some volumes is imported into RHGSWA." What log entries are we referring here which is noisy? Is it glusterd_get_value_for_vme_entry reporting some of the unknown options or something else? Please note we need to get into a habit of reporting exact details at one go so that the first pass triaging becomes smooth. Unfortunately in the originating BZ, the commentary also doesn't capture these details which is quite unfortunate. Irrespective of that, I've had a conversation with WA team members sometime back to disable executing get-state command with volumeoptions which is a no op from WA side as of now and that's causing the unrecognized options failure from the vme entry, why is that not being taken care of yet?
OTOH, the brick log report attached indicates the log entries are due to connect/disconnect of the clients? Probably heal related commands are triggering these logs. Can you confirm this, Karthik? And if this is true, I don't consider this part of the problem to be a bug.
Coming back to glusterd_get_value_for_vme_entry failures, they are genuine as not all options would be xlator specific. Given this API is a core one which would be used by many other interfaces, hiding such logs can avoid debuggability. So not a bug to me.
Regarding disabling get-state of volume-options, yes that could removed. Gowtham, can do an impact analysis of disabling this?
(In reply to Atin Mukherjee from comment #4) > OTOH, the brick log report attached indicates the log entries are due to > connect/disconnect of the clients? Probably heal related commands are > triggering these logs. Can you confirm this, Karthik? And if this is true, I > don't consider this part of the problem to be a bug. Whenever there is a new client connect/disconnect these messages are logged. Since heal is also a client process, heal related commands also generates these log messages. This can not be considered as a bug IMO.