Description of problem: ======================== An event 'TIER_ATTACH_FORCE' is mentioned in the link http://gluster.readthedocs.io/en/latest/Administrator%20Guide/Events%20APIs/, which should be generated when a hot tier is attached forcefully. When a tier is attached to an existing volume using the option 'force', no event with the type 'TIER_ATTACH_FORCE' is captured in the webhook listener. The same command when given without 'force' option does generate a 'TIER_ATTACH' event. The rest of the events like 'BRICK_CONNECTED', 'SVC_CONNECTED', 'AFR_SUBVOL_UP', 'EC_MIN_BRICKS_UP' are seen in both - with or without the force option. Version-Release number of selected component (if applicable): ============================================================ 3.8.4-2 How reproducible: ================== 2:2 Steps to Reproduce: =================== 1. Have a 4 node cluster with eventing enabled. 2. Create a 1*(4+2) disperse volume 'disp' using the bricks N1:b1, N2:b1, N3:b1, N1:b2, N2:b2, N3:b2 3. Attach a hot tier 2*2 using the bricks N4:b1, N4:b2, N4:b3, N4:b4 using the command 'gluster volume disp attach-tier <bricks> force' Actual results: ================ Step 3 generates the all the internal events like BRICK_CONNECTED, SVC_CONNECTED, AFR_SUBVOL_UP, EC_MIN_BRICKS_UP. It does not generate a TIER_ATTACH_FORCE event Expected results: ================== TIER_ATTACH_FORCE event should be seen along with the above mentioned events. Additional info: ================= [root@dhcp46-242 ~]# gluster peer status Number of Peers: 3 Hostname: dhcp46-239.lab.eng.blr.redhat.com Uuid: ed362eb3-421c-4a25-ad0e-82ef157ea328 State: Peer in Cluster (Connected) Hostname: 10.70.46.240 Uuid: 72c4f894-61f7-433e-a546-4ad2d7f0a176 State: Peer in Cluster (Connected) Hostname: 10.70.46.218 Uuid: 0dea52e0-8c32-4616-8ef8-16db16120eaa State: Peer in Cluster (Connected) [root@dhcp46-242 ~]# [root@dhcp46-242 ~]# [root@dhcp46-242 ~]# rpm -qa | grep gluster glusterfs-debuginfo-3.8.4-1.el7rhgs.x86_64 glusterfs-fuse-3.8.4-2.el7rhgs.x86_64 glusterfs-cli-3.8.4-2.el7rhgs.x86_64 glusterfs-events-3.8.4-2.el7rhgs.x86_64 glusterfs-devel-3.8.4-2.el7rhgs.x86_64 glusterfs-api-devel-3.8.4-2.el7rhgs.x86_64 glusterfs-3.8.4-2.el7rhgs.x86_64 glusterfs-client-xlators-3.8.4-2.el7rhgs.x86_64 python-gluster-3.8.4-2.el7rhgs.noarch glusterfs-ganesha-3.8.4-2.el7rhgs.x86_64 glusterfs-server-3.8.4-2.el7rhgs.x86_64 nfs-ganesha-gluster-2.3.1-8.el7rhgs.x86_64 glusterfs-libs-3.8.4-2.el7rhgs.x86_64 glusterfs-api-3.8.4-2.el7rhgs.x86_64 glusterfs-geo-replication-3.8.4-2.el7rhgs.x86_64 glusterfs-rdma-3.8.4-2.el7rhgs.x86_64 [root@dhcp46-242 ~]# [root@dhcp46-242 ~]# gluster v info Volume Name: disp Type: Disperse Volume ID: a9999464-b094-4213-a422-c11fed555674 Status: Started Snapshot Count: 0 Number of Bricks: 1 x (4 + 2) = 6 Transport-type: tcp Bricks: Brick1: 10.70.46.239:/bricks/brick0/disp1 Brick2: 10.70.46.240:/bricks/brick0/disp2 Brick3: 10.70.46.242:/bricks/brick0/disp3 Brick4: 10.70.46.242:/bricks/brick1/disp4 Brick5: 10.70.46.239:/bricks/brick1/disp5 Brick6: 10.70.46.240:/bricks/brick1/disp6 Options Reconfigured: features.barrier: disable performance.readdir-ahead: on transport.address-family: inet cluster.watermark-low: 10 cluster.watermark-hi: 20 cluster.enable-shared-storage: disable [root@dhcp46-242 ~]# gluster v attach-tier disp replica 2 10.70.46.218:/bricks/brick0/disp_hottier1 10.70.46.218:/bricks/brick1/disp_hottier2 10.70.46.218:/bricks/brick2/disp_hottier3 10.70.46.218:/bricks/brick3/disp_hottier4 force volume attach-tier: success Tiering Migration Functionality: disp: success: Attach tier is successful on disp. use tier status to check the status. ID: ceeaae16-5b9a-412b-b769-77f445ea5fb4 [root@dhcp46-242 ~]# >>>>>>>>>>>> WEBHOOK LISTENER >>>>>>>>>>>>>>>> bash-4.3$ grep -v "200" tier_attach_force2 | grep -v "CLIENT_CONNECT" | grep -v "CLIENT_DISCONNECT" | grep -v "###############" {u'message': {u'peer': u'10.70.46.218', u'volume': u'disp', u'brick': u'/bricks/brick0/disp_hottier1'}, u'event': u'BRICK_CONNECTED', u'ts': 1476942250, u'nodeid': u'0dea52e0-8c32-4616-8ef8-16db16120eaa'} {u'message': {u'peer': u'10.70.46.218', u'volume': u'disp', u'brick': u'/bricks/brick1/disp_hottier2'}, u'event': u'BRICK_CONNECTED', u'ts': 1476942250, u'nodeid': u'0dea52e0-8c32-4616-8ef8-16db16120eaa'} {u'message': {u'peer': u'10.70.46.218', u'volume': u'disp', u'brick': u'/bricks/brick2/disp_hottier3'}, u'event': u'BRICK_CONNECTED', u'ts': 1476942250, u'nodeid': u'0dea52e0-8c32-4616-8ef8-16db16120eaa'} {u'message': {u'peer': u'10.70.46.218', u'volume': u'disp', u'brick': u'/bricks/brick3/disp_hottier4'}, u'event': u'BRICK_CONNECTED', u'ts': 1476942251, u'nodeid': u'0dea52e0-8c32-4616-8ef8-16db16120eaa'} {u'message': {u'svc_name': u'glustershd'}, u'event': u'SVC_CONNECTED', u'ts': 1476942253, u'nodeid': u'1e8967ae-51b2-4c27-907e-a22a83107fd0'} {u'message': {u'svc_name': u'glustershd'}, u'event': u'SVC_CONNECTED', u'ts': 1476942254, u'nodeid': u'72c4f894-61f7-433e-a546-4ad2d7f0a176'} {u'message': {u'subvol': u'disp-disperse-0'}, u'event': u'EC_MIN_BRICKS_UP', u'ts': 1476942254, u'nodeid': u'1e8967ae-51b2-4c27-907e-a22a83107fd0'} {u'message': {u'subvol': u'disp-replicate-0'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942254, u'nodeid': u'1e8967ae-51b2-4c27-907e-a22a83107fd0'} {u'message': {u'subvol': u'disp-replicate-1'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942254, u'nodeid': u'1e8967ae-51b2-4c27-907e-a22a83107fd0'} {u'message': {u'svc_name': u'glustershd'}, u'event': u'SVC_CONNECTED', u'ts': 1476942254, u'nodeid': u'ed362eb3-421c-4a25-ad0e-82ef157ea328'} {u'message': {u'subvol': u'disp-replicate-0'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942254, u'nodeid': u'ed362eb3-421c-4a25-ad0e-82ef157ea328'} {u'message': {u'subvol': u'disp-replicate-1'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942255, u'nodeid': u'ed362eb3-421c-4a25-ad0e-82ef157ea328'} {u'message': {u'subvol': u'disp-replicate-0'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942255, u'nodeid': u'72c4f894-61f7-433e-a546-4ad2d7f0a176'} {u'message': {u'subvol': u'disp-replicate-1'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942255, u'nodeid': u'72c4f894-61f7-433e-a546-4ad2d7f0a176'} {u'message': {u'svc_name': u'glustershd'}, u'event': u'SVC_CONNECTED', u'ts': 1476942255, u'nodeid': u'0dea52e0-8c32-4616-8ef8-16db16120eaa'} {u'message': {u'subvol': u'disp-replicate-0'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942256, u'nodeid': u'0dea52e0-8c32-4616-8ef8-16db16120eaa'} {u'message': {u'subvol': u'disp-replicate-1'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942256, u'nodeid': u'0dea52e0-8c32-4616-8ef8-16db16120eaa'} {u'message': {u'subvol': u'disp-disperse-0'}, u'event': u'EC_MIN_BRICKS_UP', u'ts': 1476942259, u'nodeid': u'ed362eb3-421c-4a25-ad0e-82ef157ea328'} {u'message': {u'subvol': u'disp-disperse-0'}, u'event': u'EC_MIN_BRICKS_UP', u'ts': 1476942259, u'nodeid': u'0dea52e0-8c32-4616-8ef8-16db16120eaa'} {u'message': {u'subvol': u'disp-disperse-0'}, u'event': u'EC_MIN_BRICKS_UP', u'ts': 1476942259, u'nodeid': u'72c4f894-61f7-433e-a546-4ad2d7f0a176'} {u'message': {u'subvol': u'disp-replicate-0'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942264, u'nodeid': u'1e8967ae-51b2-4c27-907e-a22a83107fd0'} {u'message': {u'subvol': u'disp-replicate-1'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942264, u'nodeid': u'1e8967ae-51b2-4c27-907e-a22a83107fd0'} {u'message': {u'subvol': u'disp-disperse-0'}, u'event': u'EC_MIN_BRICKS_UP', u'ts': 1476942264, u'nodeid': u'1e8967ae-51b2-4c27-907e-a22a83107fd0'} {u'message': {u'subvol': u'disp-disperse-0'}, u'event': u'EC_MIN_BRICKS_UP', u'ts': 1476942264, u'nodeid': u'0dea52e0-8c32-4616-8ef8-16db16120eaa'} {u'message': {u'subvol': u'disp-replicate-0'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942264, u'nodeid': u'0dea52e0-8c32-4616-8ef8-16db16120eaa'} {u'message': {u'subvol': u'disp-disperse-0'}, u'event': u'EC_MIN_BRICKS_UP', u'ts': 1476942264, u'nodeid': u'ed362eb3-421c-4a25-ad0e-82ef157ea328'} {u'message': {u'subvol': u'disp-replicate-0'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942264, u'nodeid': u'ed362eb3-421c-4a25-ad0e-82ef157ea328'} {u'message': {u'subvol': u'disp-replicate-1'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942264, u'nodeid': u'ed362eb3-421c-4a25-ad0e-82ef157ea328'} {u'message': {u'subvol': u'disp-replicate-1'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942264, u'nodeid': u'0dea52e0-8c32-4616-8ef8-16db16120eaa'} {u'message': {u'subvol': u'disp-disperse-0'}, u'event': u'EC_MIN_BRICKS_UP', u'ts': 1476942264, u'nodeid': u'72c4f894-61f7-433e-a546-4ad2d7f0a176'} {u'message': {u'subvol': u'disp-replicate-1'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942264, u'nodeid': u'72c4f894-61f7-433e-a546-4ad2d7f0a176'} {u'message': {u'subvol': u'disp-replicate-0'}, u'event': u'AFR_SUBVOL_UP', u'ts': 1476942264, u'nodeid': u'72c4f894-61f7-433e-a546-4ad2d7f0a176'} bash-4.3$
Sweta - We now have eventsapi component created, please use this component to file all eventing bugs.
Commands attach-tier and detach-tier are deprecated. You will not see tier events if you use these commands. Please use "tier <vol> attach" and "tier <vol> detach".
(In reply to Milind Changire from comment #3) > Commands attach-tier and detach-tier are deprecated. You will not see tier > events if you use these commands. > > Please use "tier <vol> attach" and "tier <vol> detach". Are they deprecated or going to be deprecated? In former, how are we allowing the command to go through?
Deprecated implies something that is disapproved, not necessarily unavailable. Deprecated implies something that may be unavailable in the future. For reference: https://en.wikipedia.org/wiki/Deprecation
I second Atin's concern. If they are deprecated, then: - are we disallowing the users to NOT use the command, by error'ing out with the message that this command is no longer valid? OR - are we printing out a warning message saying that 'these commands are deprecated, and no longer considered safe to see the intended behaviour'? When I check in 3.8.4-2 rpm bits, we are doing neither of the above. If the idea of deprecation is in-the-books (admin guide) - that does not come across to be sufficient. As per the user, if the command is seen, it exists -> if it exists and does not error out, it works -> if it works, an event should be seen.
I am sure there must be a tiering BZ for tracking removal of support for 'gluster volume attach-tier' and 'gluster volume detach-tier'. Is that targeted for 3.2? If it is, we can rest on that front and move this BZ to its closure. If that is not targeted for 3.2, we are going to be shipping a release with the above commands very much functional. And if they are functional, we would need events to be supported in them.
I don't think we can deprecate (disable the old CLI semantics) the CLI right away, it would require some effort. For now, can we do the following? Add an warning message mentioning this CLI will be deprecated and asked for a confirmation before proceeding (this needs a BZ though)? With that there would be a right message going towards the user discouraging to use it and in that case we need not to generate events? Sweta, Milind - Thoughts?
I can see the following in mainline master bits ... # gluster volume help ... volume attach-tier <VOLNAME> [<replica COUNT>] <NEW-BRICK>... - NOTE: this is old syntax, will be depreciated in next release. Please use gluster volume tier <vol> attach [<replica COUNT>] <NEW-BRICK>... ... volume detach-tier <VOLNAME> <start|stop|status|commit|force> - NOTE: this is old syntax, will be depreciated in next release. Please use gluster volume tier <vol> detach {start|stop|commit} [force] ----- However, the help text for attach-tier and detach-tier does not mention that these commands are deprecated. Maybe the engineer missed adding the deprecation text here. This behavior is nothing new in mainline master as of today and should be seen with glusterfs-3.8.4-2 bits as well. According to git blame, the deprecation text was added by Dan on 2015-08-21 06:45:46 -0400.
Yes, adding the above note (mentioned in comment 9) in the help text of 'gluster volume attach-tier' and 'gluster volume detach-tier' AND A confirmatory message (when the command is triggered) asking the user 'if he would really want to go ahead with a _deprecated_ command' should be sufficient to discourage the user from trying out these. And if he/she still chooses to go ahead in the forbidden path, it is okay for events to not be seen. Sounds fair. P.S. Just curious, is it a significant-code-change/substantial-effort to add eventing support in the code-path of above commands?
(In reply to Sweta Anandpara from comment #10) > Yes, adding the above note (mentioned in comment 9) in the help text of > 'gluster volume attach-tier' and 'gluster volume detach-tier' > AND > A confirmatory message (when the command is triggered) asking the user 'if > he would really want to go ahead with a _deprecated_ command' > > should be sufficient to discourage the user from trying out these. And if > he/she still chooses to go ahead in the forbidden path, it is okay for > events to not be seen. Sounds fair. > > > > P.S. > Just curious, is it a significant-code-change/substantial-effort to add > eventing support in the code-path of above commands? My only concern is to add events in this release and then take them out in next given they are no longer valid, that's a waste of an effort to me.
This bug can be closed as won't fix once BZ 1388464 is fixed.
Given BZ 1388464 is now been fixed, closing this bug.