[Gluster-Maintainers] port allocation change for 3.8, needs release-notes update

[Niels de Vos]

On Mon, Sep 12, 2016 at 12:56:10PM +0530, Avra Sengupta wrote:
> On 09/07/2016 08:33 PM, Niels de Vos wrote:
> > Hi Avra,
> > 
> > http://review.gluster.org/15308 is one of your patches, and this changes
> > the allocation of ports used. It seems to address a real problem, so it
> > is acceptible to include it in 3.8.
> > 
> > Because it is a user facing change (different ports), we need to mention
> > the difference in behaviour in the release notes. Could you provide me
> > with a suitable text that includes the problem being addressed, and how
> > the usage of ports differs from before?
> > 
> > Thanks,
> > Niels
> Hi Niels,
> 
> Please find below the text to address the problem and the change in behavior
> now.
> 
> Problem: glusterd used to assume that the brick port which was previously
> allocated to a brick, would still be available, and in doing so would reuse
> the port for the brick without registering with the port map server. The
> port map server would not be aware of the brick reusing the same port, and
> try to allocate it to another process, and in turn result in that process'
> failure to connect to the port.
> 
> Fix and port usage changes: With the fix, we force glusterd, to unregister a
> port previously used by the brick, and register a new port with the port map
> server and then use it. As a result of this change, there will be no
> conflict between processes competing over the same port, thereby fixing the
> issue. Also because of this change, a brick process on restart is not
> guaranteed to reuse the same port it used to be connected to.

Thanks Avra, this looks good to me. Could you add a line about how
clients do not get confisde by this?

Niels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/maintainers/attachments/20160919/ab433a14/attachment.sig>