StarlingX/Networking
Contents
StarlingX Networking Sub-project
Team Information
- Project Lead: Ghada Khalil <ghada.khalil@windriver.com> / Forrest Zhao <forrest.zhao@intel.com>
- Technical Lead: Matt Peters <Matt.Peters@windriver.com> / Ruijing Guo <ruijing.guo@intel.com>
- Contributors: Ruijing Guo <ruijing.guo@intel.com>; Matt Peters <Matt.Peters@windriver.com>; Brent Rowsell <Brent.Rowsell@windriver.com>; Ghada Khalil <Ghada.Khalil@windriver.com>; Allain Legacy <Allain.Legacy@windriver.com>; Steven Webster <Steven.Webster@windriver.com>; Joseph Richard <Joseph.Richard@windriver.com>; Teresa Ho <Teresa.Ho@windriver.com>; Patrick Bonnell <Patrick.Bonnell@windriver.com>; Kailun Qin <kailun.qin@intel.com>; Huifeng Le <huifeng.le@intel.com>; Chenjie Xu <chenjie.xu@intel.com>; Forrest Zhao <forrest.zhao@intel.com>
Team Meeting
- Bi-weekly Meetings:
- Thursday 9:15am Eastern / 6:15am Pacific / 9:15pm(summer) or 10:15pm(winter) China
- Zoom link: https://zoom.us/j/342730236
- Meeting Agenda and Minutes:
Team Objective / Priorities
- Responsible for developing features and addressing bugs related to StarlingX networking
- Short Term Priorities (2018)
- Upstream and/or resolve the networking patches carried by StarlingX
- Implement StarlingX enhancements related to ovs-dpdk (see story board links below)
- Fix StarlingX networking-related bugs (see launchpad links below)
- This includes issues with running StarlingX and DPDK in a virtual environment; more info has been requested from the reporter.
- Long Term Priorities (2019)
- Containerized VNF support (if not already supported)
- Implement support for Time Sensitive Networking
- Integrate with ONAP and ONAP multi-cloud
Tags
All story board stories and launchpad bugs created for this team should use the tag "stx.networking".
Team Work Items
- Story Board
- All
- Active Release - stx.2.0
- Launchpad Bugs
- All
- Active Release - stx.2.0
Status
- See etherpad for weekly status updates: https://etherpad.openstack.org/p/stx-networking
Useful Networking Commands
- When deploying OVS-DPDK, VMs must be configured to use a flavor with property: hw:mem_page_size=large
- Configuring Networking Features
- Consult the configuration section of openstack networking guide on how to configure the different features supported by neutron
- For StarlingX, the configuration must be specified using helm-overrides. A direct change to the neutron.conf file is not supported for StarlingX. See examples below.
- Useful References:
- For more information on helm-overrides in StarlingX, consult the StarlngX containers FAQ
- Using helm-overrides to enable the qos extension for neutron
# create a yaml file to enable the qos extension for neutron cat > neutron-overrides.yaml <<EOF conf: neutron: DEFAULT: service_plugins: - router - network_segment_range - qos plugins: ml2_conf: ml2: extension_drivers: - port_security - qos openvswitch_agent: agent: extensions: - qos EOF # update the neutron overrides and apply to stx-openstack source /etc/platform/openrc system helm-override-update stx-openstack neutron openstack --values neutron-overrides.yaml system application-apply stx-openstack # in a separate shell, create the qos policy export OS_CLOUD=openstack_helm openstack network qos policy create bw-limit
- Using helm-overrides to enable the trunk extension for neutron
# create a yaml file to enable the trunk extension for neutron cat > neutron-overrides.yaml <<EOF conf: neutron: DEFAULT: service_plugins: - router - network_segment_range - trunk EOF # update the neutron overrides and apply to stx-openstack source /etc/platform/openrc system helm-override-update stx-openstack neutron openstack --values neutron-overrides.yaml system application-apply stx-openstack # In a separate shell, verify that the Trunk Extension and Trunk port details extensions are enabled export OS_CLOUD=openstack_helm openstack extension list --network | grep -i trunk
- Using Calico global network policy to allow access to a host service
# create GlobalNetworkPolicy for VIM webserver access kubectl apply -f - <<EOF apiVersion: crd.projectcalico.org/v1 kind: GlobalNetworkPolicy metadata: name: allow-vim-webserver spec: ingress: - action: Allow destination: ports: - 32323 protocol: TCP order: 500 selector: has(iftype) && iftype == 'oam' types: - Ingress EOF
- Using helm-overrides to add configuration rpc_response_max_timeout in neutron.conf
# Maximum rpc timeout is now configurable by rpc_response_max_timeout from Neutron config instead of being calculated as 10 * rpc_response_timeout. This configuration can be used to change the maximum rpc timeout. If maximum rpc timeout is too big, some requests which should fail will be held for a long time before the server returns failure. If this value is too small and the server is very busy, the requests may need longer time than maximum rpc timeout and the requests will fail though they can succeed with a bigger maximum rpc timeout. # create a yaml file to add configuration rpc_response_max_timeout in neutron.conf cat > neutron-overrides.yaml <<EOF conf: neutron: DEFAULT: rpc_response_max_timeout: 600 EOF # update the neutron overrides and apply to stx-openstack source /etc/platform/openrc system helm-override-update stx-openstack neutron openstack --values neutron-overrides.yaml system application-apply stx-openstack # verify that configuration rpc_response_max_time has been added in neutron.conf kubectl get pod -n openstack | grep neutron kubectl exec -it $neutron-server -n openstack bash cat /etc/neutron/neutron.conf | grep rpc_response_max_timeout