Description of problem: If volume having 4 brick then listening port for that brick will be 49152-49155. if user perform any remove-brick operation then one of the brick port from 49152-49155 will free (port on which user performing remove brick operation). after this if user perform add-brick operation then glusterd will assign port after 49155, it is not reusing the port which is freed by remove-brick operation. Version-Release number of selected component (if applicable): Mainline How reproducible: Always Steps to Reproduce: 1. Create and start volume having 2 or more than 2 brick. 2. perform remove-brick operation on any brick. 3. execute gluster volume status command. 3. perform add-brick operation. 4. execute gluster volume status command. you will see that the brick which you have recently added will use new port. Actual results: brick which you have recently added will use new port Expected results: we should re-use the port which is free by remove-brick command.
REVIEW: http://review.gluster.org/10785 (glusterd: newly added brick should use the port which is freed by remove-brick) posted (#1) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: newly added brick should use the port which is freed by remove-brick) posted (#2) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: newly added brick should use the port which is freed by remove-brick) posted (#3) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: newly added brick should use the port which is freed by remove-brick) posted (#4) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: newly added brick should use the port which is freed by remove-brick) posted (#5) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: newly added brick should use the port which is freed by remove-brick) posted (#6) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: allocate new port from base port instead of last allocated port) posted (#7) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: allocate new port from base port instead of last allocated port) posted (#8) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: reuse a freed up port in portmap) posted (#9) for review on master by Gaurav Kumar Garg (ggarg)
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
REVIEW: http://review.gluster.org/10785 (glusterd: reuse a freed up port in portmap) posted (#10) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: reuse a freed up port in portmap) posted (#11) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: reuse a freed up port in portmap) posted (#12) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: reuse a freed up port in portmap) posted (#13) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: reuse a freed up port in portmap) posted (#14) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: reuse a freed up port in portmap) posted (#15) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: reuse a freed up port in portmap) posted (#16) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: reuse a freed up port in portmap) posted (#17) for review on master by Gaurav Kumar Garg (ggarg)
REVIEW: http://review.gluster.org/10785 (glusterd: reuse a freed up port in portmap) posted (#18) for review on master by Atin Mukherjee (amukherj)
REVIEW: http://review.gluster.org/10785 (glusterd: reuse a freed up port from portmap table) posted (#19) for review on master by Atin Mukherjee (amukherj)
REVIEW: http://review.gluster.org/14939 (glusterd: search for free port from base_port) posted (#2) for review on master by Atin Mukherjee (amukherj)
COMMIT: http://review.gluster.org/14939 committed in master by Jeff Darcy (jdarcy) ------ commit 7abed939a7cc61880aed7547f12ace80e6128170 Author: Atin Mukherjee <amukherj> Date: Mon Jul 18 12:54:38 2016 +0530 glusterd: search for free port from base_port When a volume is deleted, the freed up ports are never considered for further allocation since pmap_registry_alloc () always starts scanning from last_alloc. So in use cases where gluster volumes are frequently created and deleted managing ports become nightmare as for every new volume creation ports need to be opened up by the admin based on the volume topology. Solution: Instead of scanning from last_alloc, pmap_registry_alloc () always starts from base_port now. What that means is glusterd will always try to find out the ports which have been freed from earlier volumes and reallocate them for the newer ones. There could be possibilities that when a volume is stopped and started back their brick ports are changed which is completely acceptible IMHO. Change-Id: I99ccc11732b6a75527fcb6abafaf249ed02b3b78 BUG: 1221623 Signed-off-by: Atin Mukherjee <amukherj> Reviewed-on: http://review.gluster.org/14939 CentOS-regression: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> Reviewed-by: Jeff Darcy <jdarcy> Smoke: Gluster Build System <jenkins.org>
We'd need one more patch to get this issue completely resolved. Moving this bug to POST state.
REVIEW: http://review.gluster.org/15005 (glusterd: Mark brick port leased before starting the bricks) posted (#2) for review on master by Atin Mukherjee (amukherj)
REVIEW: http://review.gluster.org/15005 (glusterd: Mark brick port leased before starting the bricks) posted (#3) for review on master by Atin Mukherjee (amukherj)
REVIEW: http://review.gluster.org/15005 (glusterd: Mark brick port leased before starting the bricks) posted (#4) for review on master by Atin Mukherjee (amukherj)
REVIEW: http://review.gluster.org/15005 (glusterd: Mark brick port leased before starting the bricks) posted (#5) for review on master by Atin Mukherjee (amukherj)
REVIEW: http://review.gluster.org/15005 (glusterd: Mark brick port leased before starting the bricks) posted (#6) for review on master by Atin Mukherjee (amukherj)
REVIEW: http://review.gluster.org/15005 (glusterd: clean up old port and allocate new one on every restart) posted (#7) for review on master by Atin Mukherjee (amukherj)
REVIEW: http://review.gluster.org/15005 (glusterd: clean up old port and allocate new one on every restart) posted (#8) for review on master by Atin Mukherjee (amukherj)
COMMIT: http://review.gluster.org/15005 committed in master by Atin Mukherjee (amukherj) ------ commit c3dee6d35326c6495591eb5bbf7f52f64031e2c4 Author: Atin Mukherjee <amukherj> Date: Mon Jul 25 19:09:08 2016 +0530 glusterd: clean up old port and allocate new one on every restart GlusterD as of now was blindly assuming that the brick port which was already allocated would be available to be reused and that assumption is absolutely wrong. Solution : On first attempt, we thought GlusterD should check if the already allocated brick ports are free, if not allocate new port and pass it to the daemon. But with that approach there is a possibility that if PMAP_SIGNOUT is missed out, the stale port will be given back to the clients where connection will keep on failing. Now given the port allocation always start from base_port, if everytime a new port has to be allocated for the daemons, the port range will still be under control. So this fix tries to clean up old port using pmap_registry_remove () if any and then goes for pmap_registry_alloc () Change-Id: If54a055d01ab0cbc06589dc1191d8fc52eb2c84f BUG: 1221623 Signed-off-by: Atin Mukherjee <amukherj> Reviewed-on: http://review.gluster.org/15005 Smoke: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> Reviewed-by: Avra Sengupta <asengupt>