Hi Niels,
Can we have this in the next 3.8 build. Without this fix, bricks and
snapd are susceptible to be down. Thanks.
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
_______________________________________________
maintainers mailing list
[email protected]
http://www.gluster.org/mailman/listinfo/maintainers
