[Starlingx-discuss] Minutes: StarlingX Networking Meeting - 03/21
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.htm... 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-5ePOaSSkKD1... - 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
participants (1)
-
Khalil, Ghada