[Starlingx-discuss] Question about patch upstreaming for a38f899

[Peters, Matt]

Hi Kailun,
Looking at the remaining items that you had in the attachment,  I agree with your assessment of the changes.

I don't have any further information on how to reproduce the first item, other than to run the tempest tests in a multi-core environment repeatedly to try and trigger the race condition.  However, since the tests may have changed from the time of the original commit, it may be that this scenario can no longer be triggered.

-Matt

From: Peters, Matt [mailto:Matt.Peters at windriver.com]
Sent: Monday, October 15, 2018 1:05 PM
To: Qin, Kailun; Legacy, Allain
Cc: starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] Question about patch upstreaming for a38f899

Based on the original commit message (see below), it would fall into scenario #2.  However, as the commit message indicates, this is based on race conditions when running tempest, therefore it may not be easily reproducible.


    CGTS-3885: dhcp: handle concurrent port creation errors

    Running tempest nose tests exposes a race condition between the server
    deleting a subnet and an agent creating a DHCP port.  This problem manifests
    itself in different ways depending on the whether the error is returned to the
    subnet delete operation or the DHCP port creation.

    This Jira (3885) addresses how the error is handled by the agent when the
    subnet is concurrently deleted at the server.  The changes to address the error
    that is returned to the API client are in CGTS-3432.

    Because of how the server and agents are designed there is a lack of
    determinism in how this particular issue manifests itself.  The variants
    manifest themselves based on when the subnet is deleted in relation to when the
    port is created.

      1) if the port is returned with no fixed IP address then this results in the
      agent failing to setup the default route in the namespace because there is no
      local IP address to use to contact the gateway IP address.

      2) if the port is updated after creation to no longer have an IP address then
      'reload_allocations' action is invoked instead of the 'disabled' action.
      This leads to a failure to reenable because the subnet no longer exits.

      3) if doing a 'disable' action it is possible that previous 'restart',
      'enable', or 'reload' actions did not get far enough to create the
      namespace.  For this reason we should not throw an error if the namespace
      does not exist.

      4) if attempting a 'reload_allocations' we should fail the request if the
      namespace does not exist.

      5) if attempting a 'reload_allocations' with retain_port=True we should not
      delete the configuration files because the vswitch port name is stored in the
      'interface' file.  If an error occurs during the enable action we will not be
      able to 'unplug' the port from the vswitch because we will not know which
      name to use during the 'unplug'.  This will leak ports in the vswitch.

From: Qin, Kailun [mailto:kailun.qin at intel.com]
Sent: Monday, October 15, 2018 5:00 AM
To: Peters, Matt; Legacy, Allain
Cc: starlingx-discuss at lists.starlingx.io
Subject: Question about patch upstreaming for a38f899

Hi Matt, Allain,

I am analyzing the patch a38f899 for upstreaming. It seems to me that parts of the patch have already been addressed by upstream, while some of the rest may need your double confirm/clarification.

Please kindly check the attached analysis report for further details.

Let me know if any question. Thanks a lot!

BR,
Kailun

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20181018/325b62f3/attachment.html>