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@intel.com]
Sent: Monday, October 15, 2018 5:00 AM
To: Peters, Matt; Legacy, Allain
Cc: starlingx-discuss@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