[Starlingx-discuss] Minutes: StarlingX Networking Meeting - 03/21

[Khalil, Ghada]

Meeting minutes/agenda are captured at:
https://etherpad.openstack.org/p/stx-networking


Team Meeting Agenda/Notes - Mar 21/2019
- Kickoff joint planning with Neutron upstream for the Train cycle PTG (mlavalle):
        - http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003895.html   and
        - https://etherpad.openstack.org/p/openstack-networking-train-ptg 
        - L2/L3 rescheduling/rebalancing - to continue the effort discussed in Stein PTG?
              - https://review.openstack.org/#/c/595978/
              - proposals: 1) scripts in Neutron or 2) plugin running rescheduling/rebalancing services out of Neutron (e.g. in STX repo)
              - StarlingX is implementing agent rescheduling/rebalancing in the VIM: https://storyboard.openstack.org/#!/story/2003857
              - No additional functionality required in neutron
        - Other Gaps in StarlingX after rebase to Stein?
              - Port Forwarding for Floating IP is not in openstack client
                      - StoryBoard already exists for openstack client: https://storyboard.openstack.org/#!/story/2004924 
                      - If community is not implementing this, we should take over the implementation. Action: Forrest to resource once train implementation cycle is started.
              - Other items TBD - StarlingX just recently rebased to master/stein. Need to monitor and bring up any items
                      - There may be small items / bug reports found during testing
                      - We don't believe there are any major gaps in neutron that StarlingX needs for train
        - OVS VLAN transparent
              - It would be good to discuss with the neutron community the rationale behind not implementing this feature, but not a priority for StarlingX in train
        - L2POP  (and more generally BGP EVPN)
              - The majority of the l2pop patches were related to BGP EVPN. This is still a low priority for StarlingX.
              - BGP EVPN should be discussed for StarlingX in the PTG, but it's not likely this will be required for the next release
              - https://blueprints.launchpad.net/neutron/+spec/native-l2pop 
                      - l2pop is being obsoleted, so we would need to re-work our proposal to the community if we want to pursue this

- Neutron Patches -- Discuss next steps for patches not making Stein
        - Spreadsheet: https://docs.google.com/spreadsheets/d/1udAtEpQljV2JZVs-525UhWyx-5ePOaSSkKD1CS27ohU/edit#gid=0 
        - Prevent DHCP from processing stale RPC messages (fd6cfc) - Kailun - RFE
              - This is a robustness item, so we want to continue pursuing this in train
        - 0039-dhcp-handle-concurrent-port-creation-error.patch (a38f89) - Kailun
              - Help needed on reproduction under concurrency
              - Put on hold for now.  Wait to see if any issues come out of testing with Stein.
        - 0147-CGTS-8844-ml2-use-new-bindings-when-failing-concurre.patch (da31d0) - Kailun
              - Need community triage firstly: https://bugs.launchpad.net/neutron/+bug/1755810 
              - Continue to pursue in train
        - 0047-wsgi-prevent-accepting-socket-without-a-gr.patch (8e72491) - Huifeng
              - Discuss in the PTG whether the neutron community is planning to move to the wsgi 
        - 0062-dvr-force-admin-state-update-before-distri.patch (edf9731) - Matt W
              - Refreshing this patch. Continue to pursue in train. 
              - This is not serious enough to push for a backport to Stein
        - 0065-dvr-do-not-create-agent-gateway-ports-unle.patch (2857911) - Enyinna
              - Continue to pursue in train

- Containerized OVS Integration
        - Code Merge Plan: Mar 22  (may have a few days delay to go thru code inspection/merge)
        - stx-config code review: https://review.openstack.org/#/c/633924/ 
        - Testing:
              - simplex and dumplex tests are finished, result is updated on story https://storyboard.openstack.org/#!/story/2004649#comment-118416 
              - multi node standard deployment vswitch_type=ovs-dpdk is finished, result is updated on story https://storyboard.openstack.org/#!/story/2004649#comment-119007 
              - multi node standard deployment vswitch_type=none test is finished, result is updated here  https://storyboard.openstack.org/#!/story/2004649#comment-119007 
        - Ready to merge once the code review is done: Matt & Joseph to review. Then Ghada to follow up with core reviewers as needed.
        - Once the code merges, Cheng needs to update the Install wiki to indicate that OVS is the default config, that OVS must be used for a vitual env, ...etc.
        - Also an email should be sent to StarlingX discuss list

- openvswitch package Upversion
        - Code Merge Plan: Apr 5
        - Issues w/ VM connectivity even seen on cengn load; issues not seen in WR labs
        - What are the next steps to investigate/address?
              - https://bugs.launchpad.net/starlingx/+bug/1820378    (reproduced on the cengn 03-05-2019 in Intel env)
        - Basic Functional Testing done and following bugs have been reported:
              - https://bugs.launchpad.net/starlingx/+bug/1821150 
              - https://bugs.launchpad.net/starlingx/+bug/1821135 
              - workaround doesn't work if different bridge name on different compute nodes
        - None of the 3 issues above are seen in WR labs using cengn load
              - Need to check that the latest docker images and armada manifests are being used
              - Suggest Chenjie shares the checksums from his env so that Matt can compare them to our env
        - Ada's team still needs to do regression testing as well as Mellanox testing before the code would merge

- OVS-DPDK Firewall
        - Code Merge Plan: Mar 22 >> ??
        - Given the move to containers, the code has to be moved from the puppet manifest to the Armada manifest (minor change). Then need a re-test in the container env.
              - stx-config change: https://review.openstack.org/#/c/645054/ 
              - Only 1 multi-node HW env currently used for tests of containerized OVS integration
              - Since OVS-DPDK is not containerized and we've already done full OVS-DPDK firewall functional testing w/o containers, the functional testing done in openvswitch pkg upversion should be enough.
              - Will finish performance testing once the env is available.
        - Need new forecast. Action: Forrest to update

- OVS process monitoring and alarming
        - Code Merge Plan: Mar 22 >> ??
        - Still on hold due to OVS-DPDK Upverison testing
        - Need new forecast given the issues w/ openvswitch package upversion.

- Kubenetes cluster network issues update:
        - https://bugs.launchpad.net/starlingx/+bug/1819738 : need to check whether it is by design
              - No this is a bug
        - https://bugs.launchpad.net/starlingx/+bug/1819492 : need to check whether the test case configuration is valid
              - Yes the config is valid; It's valid configuration to have the cluster-host interface tagged on the management interface with LAG mode
        - https://bugs.launchpad.net/starlingx/+bug/1820115 : some questions require help for clarification