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

[Niels de Vos]

On Mon, Nov 21, 2016 at 11:46:39AM +0530, Avra Sengupta wrote:
> Hi Niels,
> 
> Can we have this in the next 3.8 build. Without this fix, bricks and snapd
> are susceptible to be down. Thanks.

Yes, I am planning to do a 3.8.6 build last week and want to include
this change. Things are rather busy for me, and I'm a little behind on
schedule.

Thanks,
Niels


> 
> Regards,
> Avra
> 
> On 11/15/2016 11:46 AM, Avra Sengupta wrote:
> > Hi Niels,
> > 
> > I don't think there is anything more to add to the release note, in
> > regards to this patch (http://review.gluster.org/#/c/15308/). Given that
> > it is a crucial fix, I think we should take this in without further
> > delay. Thanks.
> > 
> > Regards,
> > Avra
> > 
> > On 09/19/2016 03:07 PM, Niels de Vos wrote:
> > > On Mon, Sep 19, 2016 at 01:43:29PM +0530, Avra Sengupta wrote:
> > > > 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.
> > > > Client processes
> > > > are unaffected by this change, as they do a portmap query before
> > > > connecting to
> > > > the brick processes.
> > > Great, thanks!
> > > 
> > > Niels
> > > 
> > > > 
> > > > On 09/19/2016 01:25 PM, Niels de Vos wrote:
> > > > > 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/20161122/f3997b3f/attachment.sig>