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

[Avra Sengupta]

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.


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