[Gluster-Maintainers] port allocation change for 3.8, needs release-notes update
Avra Sengupta
asengupt at redhat.com
Tue Nov 15 06:16:24 UTC 2016
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
More information about the maintainers
mailing list