Revision as of 08:56, 10 July 2019

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:
- https://etherpad.openstack.org/p/stx-networking

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

Team Work Items

Story Board
- All
  - Active Stories
  - Merged Stories
- Active Release - stx.2.0
  - Active Stories
Launchpad Bugs
- All
  - Open Bugs
  - Fixed Bugs
- Active Release - stx.2.0
  - Open Bugs

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:
  - StarlingX Armada manifest
  - openstack-helm neutron values
- 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 return failure 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

Difference between revisions of "StarlingX/Networking"

Revision as of 08:56, 10 July 2019

Contents

StarlingX Networking Sub-project

Team Information

Team Meeting

Team Objective / Priorities

Tags

Team Work Items

Status

Useful Networking Commands