[Starlingx-discuss] Analysis report about Network Trunk feature for StartlingX upstreaming

[Jolliffe, Ian]

Hi Huifeng;

Thanks for the updates/analysis, comments below.

Ian

Ian/Brent/Matt,

We did analysis about the Network trunk related patches for StartingX upstream, below are the suggestions for upstreaming, could you please help to review and comment? Thanks much!

1.  ba9d9f60a7a2665194cacb92a05e0acd2dc3de41: Add rpc notification for trunk updates
     Function: sent notification to the agent when a trunk is updated
     Analysis:
      (1)Trunk’s AFTER_UPDATE event is generated for API call: PUT /v2.0/trunks/{trunk-id}
The update request is only for changing fields like name, description or admin_state_up. Setting the admin_state_up to False locks the trunk in that it prevents operations such as adding/removing subports.
In Neutron upstream, admin_state_up is used in server side, e.g. add_subports, remove subports, delete_trunk and not used in agent side
      (2)OVS trunk agent driver uses OVSDB event to handle trunk event, no need to manually trigger trunk update event
     (3)Linux trunk agent driver will handle trunk update event triggered by server, while it will need apply the patch only in case admin_state_up update need to be handled
     Suggestion: Not a bug for Neutron upstream, suggest not to upstream

If this is not upstreamed, are the dependencies or changes required in the StarlingX code base?  What are the implications of not upstreaming?

2. 6955351c5eca6e37061fb0140d11ea53693fe0e1: Add support to delete bound network
     Function: enable delete trunk if it is can_be_trunked (not bounded or driver’s can_trunk_bound_port=true)
     Analysis: Applied for LinuxBridge Driver and AVS bridge Driver (can_trunk_bound_port=True), no impact for OVSTrunkDriver (can_trunk_bound_port=False). workaround also available for linux bridge (e.g. unbind the port first then delete the trunk)
     Suggestion: it is a low priority bug for Neutron upstream (only applied for linux bridge and workround available), suggest not to upstream

I think you need to propose a fix.  Or this will need to be carried long term.

3. 43a684946e781a25d21a4f50b8dc67d61be42809: Enable trunk service by default
     Function: add “trunk” in DEFAULT_SERVICE_PLUGINS
     Analysis: It is a deploy configuration for downstream product
     Suggestion: Not a bug for Neutron upstream, suggest not to upstream

Agree

4. c54d804792f10b7f505de6794274c4df4768f6f0: Include trunk presence in port details
     Function: add trunk_port (bool) flag in port_details to identify whether this port is a parent port for a trunk
     Analysis: It is a performance improvement for AVS agent by reducing RPC call from agent to server. OVS agent has different implementation with no improvement by introducing this field
     Suggestion: Not a bug for Neutron upstream, suggest not to upstream

Agree


5. 3eed837ebd236e6b1959ea88d9ab5322c9eef6b9: Ignore trunk subports on same vlan as vlan-subnet ports
     Function: Ignore trunk subports on same vlan as vlan-subnet ports
     Analysis: It is a bug fix for AVS agent
     Suggestion: Not a bug for Neutron upstream, suggest not to upstream

Agree



Best Regards,
Le, Huifeng


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