Difference between revisions of "TelcoWorkingGroup"
(Add virtual IMS core as an example control plane use case) |
|||
Line 76: | Line 76: | ||
|- | |- | ||
| kalyan || Kalyanjeet Gogoi || Juniper Networks || NFV integration with OpenStack | | kalyan || Kalyanjeet Gogoi || Juniper Networks || NFV integration with OpenStack | ||
+ | |- | ||
+ | | kranthi || Kranthi Molleti || Tech Mahindra || Neutron, NFV and Virtual Networking | ||
|- | |- | ||
| LouisF || Louis Fourie || Huawei || NFV-MANO, Service Function chaining, Traffic steering | | LouisF || Louis Fourie || Huawei || NFV-MANO, Service Function chaining, Traffic steering |
Revision as of 15:02, 23 July 2014
Contents
- 1 Weekly NFV sub-team IRC meeting
- 2 What is NFV?
- 3 Who we are
- 4 Mission statement
- 5 Use Cases
- 5.1 ETSI-NFV Use Cases - High Level Description
- 5.1.1 Use Case #1: Network Functions Virtualisation Infrastructure as a Service
- 5.1.2 Use Case #2: Virtual Network Function as a Service (VNFaaS)
- 5.1.3 Use Case #3: Virtual Network Platform as a Service (VNPaaS)
- 5.1.4 Use Case #4: VNF Forwarding Graphs
- 5.1.5 Use Case #5: Virtualisation of Mobile Core Network and IMS
- 5.1.6 Use Case #6: Virtualisation of Mobile base station
- 5.1.7 Use Case #7: Virtualisation of the Home Environment
- 5.1.8 Use Case #8: Virtualisation of CDNs
- 5.1.9 Use Case #9: Fixed Access Network Functions Virtualisation
- 5.2 Contributed Use Cases
- 5.3 References:
- 5.4 Related Teams and Projects
- 5.1 ETSI-NFV Use Cases - High Level Description
- 6 Development Efforts
Weekly NFV sub-team IRC meeting
MEETING TIME: (Proposed, subject to change) Wednesdays, 1400 UTC, #openstack-meeting-alt, starting June 4
What is NFV?
NFV stands for Network Functions Virtualization. It defines the replacement of usually stand alone appliances used for high and low level network functions, such as firewalls, network address translation, intrusion detection, caching, gateways, accelerators, etc, into virtual instance or set of virtual instances, which are called Virtual Network Functions (VNF). In other words, it could be seen as replacing some of the hardware network appliances with high-performance software taking advantage of high performance para-virtual devices, other acceleration mechanisms, and smart placement of instances. The origin of NFV comes from a working group from the European Telecommunications Standards Institute (ETSI) whose work is the basis of most current implementations. The main consumers of NFV are Service providers (telecommunication providers and the like) who are looking to accelerate the deployment of new network services, and to do that, need to eliminate the constraint of slow renewal cycle of hardware appliances, which do not autoscale and limit their innovation.
NFV support for OpenStack aims to provide the best possible infrastructure for such workloads to be deployed in, while respecting the design principles of a IaaS cloud. In order for VNF to perform correctly in a cloud world, the underlying infrastructure needs to provide a certain number of functionalities which range from scheduling to networking and from orchestration to monitoring capacities. This means that to correctly support NFV use cases in OpenStack, implementations may be required across most, if not all, main OpenStack projects, starting with Neutron and Nova.
For more details on NFV, the following references may be useful:
Who we are
Add your name here if you're joining the meetings - IRC nicks are pretty anonymous unless you give us a clue! Please keep the list in alphabetical order by IRC nick.
adrian-hoban | Adrian Hoban | Intel OpenStack team | NFV & SDN extensions across OpenStack projects |
akhila-chetlapalle | Akhila Chetlapalle | TCS Openstack Team | NFV & SDN Test Framework with Openstack |
armax | Armando Migliaccio | HP | Neutron, NFV, SDN |
arosen | Aaron Rosen | nicira/vmware | Automation, SDN/Neutron/NFV, Openstack |
alank35 | Alan Kavanagh | Ericsson Inc | NFV & SDN & Neutron and ODL |
atylee | Andy Tylee | Metaswitch Networks | NFV, SR-IOV, data plane acceleration, orchestration |
balajip | Balaji Padnala | Freescale OpenStack Team | NFV, SDN, SRIOV, Libvirt, Neutron, Nova, Service VMs and Service Chaining |
banix | Mohammad Banikazemi | IBM | NFV, SDN, Neutron, OpenStack |
bauzas | Sylvain Bauza | Red Hat | SLA and Scheduling in Nova |
cdub | Chris Wright | Red Hat | NFV and SDN work between OpenStack and OpenDaylight |
cgoncalves | Carlos Goncalves | Instituto de Telecomunicacoes | Service Function Chaining, Traffic Steering |
cliljenstolpe | Christopher Liljenstolpe | Metaswitch Networks | Neutron, orchestration, network architecture |
cloudon | Calum Loudon | Metaswitch Networks | Neutron, data plane acceleration, orchestration |
danpb | Daniel Berrange | Red Hat | Libvirt, KVM & Nova performance & enablement for NFV |
davidpc | David Perez Caparros | DOCOMO Euro-Labs | Supporting NFV in OpenStack |
diga | Digambar Patil | Persistent System Ltd. | Neutron, Nova, SDN, NFV |
dmitry_huawei | Dmitry Meytin | Huawei | MANO integration with OpenStack |
eranb | Eran Bello | ASOCS | NFV compute and accelerator resources integration with OpenStack |
fjramons | Francisco-Javier Ramon Salguero | Telefonica | Libvirt, KVM & Nova performance & enablement for NFV |
ggarcia | Gerardo Garcia | Telefonica | Libvirt, KVM & Nova performance & enablement for NFV |
gc4rella | Giuseppe Carella | Fraunhofer FOKUS | NFV MANO, Service Function Chaining, SDN |
heyongli | Yongli He | Intel Openstack team | nova enabling NFV SRIOV PCI passthrough |
ian_ott | Ian Jolliffe | Wind River | Openstack, NFV, Networking |
ijw | Ian Wells | Cisco's Openstack team | Vendor neutral NFV infrastructure, Cisco NFV appliances |
imendel | Itai Mendelsohn | Alcatel-Lucent | NFV in general and how OpenStack can enable it |
irenab | Irena Berezovsky | Mellanox | NFV, SDN, NFV SRIOV PCI passthrough |
JeremyLiu | Jeremy Liu | Huawei | NFV & OpenStack |
jmsoares | Joao Soares | Portugal Telecom | Service Function Chaining, Traffic Steering |
kalyan | Kalyanjeet Gogoi | Juniper Networks | NFV integration with OpenStack |
kranthi | Kranthi Molleti | Tech Mahindra | Neutron, NFV and Virtual Networking |
LouisF | Louis Fourie | Huawei | NFV-MANO, Service Function chaining, Traffic steering |
lukego | Luke Gorrie | Snabb | Making open source NFV work for Deutsche Telekom's TeraStream project |
malini1 | Malini Bhandaru | Intel | NFV, Adv. Service VMs, compute node capabilities, security |
martin_t | Martin Taylor | Metaswitch Networks | Neutron networking and data plane acceleration |
matrohon | Mathieu Rohon | Orange | NFV, SDN, Neutron |
mjbright | Mike Bright | HP | Openstack, NFV/SDN |
mpetrus | Margaret Petrus | VMware | NFV-MANO, OpenStack for Service Orchestration |
nbal | Nuri Bal | Cyan | OpenStack support of NFV, MANO in particular |
nbouthors | Nicolas Bouthors | Qosmos | Service Chaining, Classifier VNFC |
nijaba | Nick Barcet | eNovance | NFV support on OpenStack |
prabhu-nk | Prabhuling Kalyani | Global Edge | NFV, Service Chaining |
radek | Radoslaw Smigielski | Alcatel-Lucent | OpenStack+NFV, SR-IOV, PCI passthrough, KVM performance |
r-mibu | Ryota Mibu | NEC | Nova enhancement for NFV |
ricky.bo | ricky.bo | Huawei | Help better support NFV |
rohit404 | Rohit Agarwalla | Cisco's OpenStack team | OpenStack+NFV |
rseth | Rajeev Seth | Sonus Networks | NFV integration with OpenStack |
runarut | Larry Pearson | AT&T | OpenStack as NFVI, VNF Service Chaining |
russellb | Russell Bryant | Project: OpenStack TC, Nova. Corporate: Red Hat | Nova. Ensuring requirements and designs are consumable by OpenStack developers. Reviewing designs and implementations. |
s3wong | Stephen Wong | Midokura | NFV support on OpenStack |
safchain | Sylvain Afchain | eNovance | NFV, SDN, Neutron |
sasud | S Sud | Intel | NFV and SDN use case PoCs |
sean-k-mooney | Sean Mooney | Intel OpenStack team | NFV & SDN enabling |
sgordon | Steve Gordon | Red Hat | NFV and SDN enablement across OpenStack projects but particularly Nova and the Libvirt driver. |
shane-wang | Shane Wang | Intel | NFV support on OpenStack, VM QoS in Nova, PCI/SR-IOV support |
smazziotta | Sandro Mazziotta | eNovance | OpenStack extensions required to meet NFV requirements |
thomnico | Nicolas Thomas | Canonical | Allowing OpenStack to be gradually used in NFV type of deployments ETSI NFV IG participant. |
tvvcox | Tomas Von Veschler | Red Hat | Openstack enablement for NFVi and VIM |
ulikleber | Ulrich Kleber | Huawei | Help better support NFV |
vjardin | Vincent JARDIN | 6WIND | Help using DPDK applications efficiently and ivshmem to start with (memnic) |
Venkatesh | Venkatesh | Wipro Technologies | NFV & SDN extenstions across Openstack projects |
yamahata | Isaku Yamahata | Intel | Neutron, servicevm, service chaining, traffic steering |
yjiang5 | Yunhong Jiang | Intel | Nova enablement for NFV |
yukiarbel | Yuki Arbel | Alcatel Lucent | NFV, Openstack for NFV |
zeddii | Bruce Ashfield | Wind River | KVM, libvirt, nova and platform awareness for NFV |
zuqiang | Zu Qiang | Ericsson | NFV support in OpenStack |
Mission statement
The sub-team aims to define the use cases and identify and prioritise the requirements which are needed to run Network Function Virtualization (NFV) workloads on top of OpenStack. This work includes identifying functional gaps, creating blueprints, submitting and reviewing patches to the relevant OpenStack projects and tracking their completion in support of NFV.
The requirements expressed by this group should be made so that each of them have a test case which can be verified using an OpenSource implementation. This is to ensure that tests can be done without any special hardware or proprietary software, which is key for continuous integration tests in the OpenStack gate. If special setups are required which cannot be reproduced on the standard OpenStack gate, the use cases proponent will have to provide a 3rd party CI setup, accessible by OpenStack infra, which will be used to validate developments against.
Chair: Russell Bryant (russellb)
Agenda for next meeting
Wednesday, June 4 at 1400 UTC in #openstack-meeting-alt.
Agenda: [1]
Previous meetings
Use Cases
Workload Type | Description | Characteristics | Examples | Requirements |
---|---|---|---|---|
Data plane | Tasks related to packet handing in an end-to-end communication between edge applications. |
|
|
- |
Control plane | Any other communication between network functions that is not directly related to the end-to-end data communication between edge applications. |
|
|
- |
Signal processing | All network function tasks related to digital processing |
|
|
- |
Storage | All tasks related to disk storage. |
|
|
- |
ETSI-NFV Use Cases - High Level Description
Use Case #1: Network Functions Virtualisation Infrastructure as a Service
This is a reasonably generic IaaS requirement.
Use Case #2: Virtual Network Function as a Service (VNFaaS)
This primarily targets Customer Premise Equipment (CPE) devices such as access routers, enterprise firewall, WAN optimizers etc. with some Provider Edge devices possible at a later date. ETSI-NFV Performance & portability considerations will apply to deployments that strive to meet high performance and low latency considerations.
Use Case #3: Virtual Network Platform as a Service (VNPaaS)
This is similar to #2 but at the service level. At larger scale and not at the "app" level only.
Use Case #4: VNF Forwarding Graphs
Dynamic connectivity between apps in a "service chain".
Use Case #5: Virtualisation of Mobile Core Network and IMS
Primarily focusing on Evolved Packet Core appliances such as the Mobility Management Entity (MME), Serving Gateway (S-GW), etc. and the IP Multimedia Subsystem (IMS).
Use Case #6: Virtualisation of Mobile base station
Focusing on parts of the Radio Access Network such as eNodeB's, Radio Link Control and Packet Data Convergence Protocol, etc..
Use Case #7: Virtualisation of the Home Environment
Similar to Use Case 2, but with a focus on virtualising residential devices instead of enterprise devices. Covers DHCP, NAT, PPPoE, Firewall devices, etc.
Use Case #8: Virtualisation of CDNs
Content Delivery Networks focusing on video traffic delivery.
Use Case #9: Fixed Access Network Functions Virtualisation
Wireline related access technologies.
Contributed Use Cases
Session Border Controller
Contributed by: Calum Loudon
Description
Perimeta Session Border Controller, Metaswitch Networks. Sits on the edge of a service provider's network and polices SIP and RTP (i.e. VoIP) control and media traffic passing over the access network between end-users and the core network or the trunk network between the core and another SP.
Characteristics
- Fast and guaranteed performance:
- Performance in the order of several million VoIP packets (~64-220 bytes depending on codec) per second per core (achievable on COTS hardware).
- Guarantees provided via SLAs.
- Fully high availability
- No single point of failure, service continuity over both software and hardware failures.
- Elastically scalable
- NFV orchestrator adds and removes instances in response to network demands.
- Traffic segregation (ideally)
- Separate traffic from different customers via VLANs.
Requirements
- Fast & guaranteed performance (network)
- Packets per second target -> either SR-IOV or an accelerated DPDK-like data plane:
- "SR-IOV Networking Support" (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov)
- "Open vSwitch to use patch ports" (https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use)
- "userspace vhost in ovd vif bindings" (https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost)
- "Snabb NFV driver" (https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver)
- "VIF_VHOSTUSER" (https://blueprints.launchpad.net/nova/+spec/vif-vhostuser)
- Packets per second target -> either SR-IOV or an accelerated DPDK-like data plane:
- Fast & guaranteed performance (compute):
- To optimize data rate we need to keep all working data in L3 cache:
- "Virt driver pinning guest vCPUs to host pCPUs" (https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning)
- To optimize data rate need to bind to NIC on host CPU's bus:
- "I/O (PCIe) Based NUMA Scheduling" (https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling)
- To offer guaranteed performance as opposed to 'best efforts' we need:
- To control placement of cores, minimise TLB misses and get accurate info about core topology (threads vs. hyperthreads etc.); maps to the remaining blueprints on NUMA & vCPU topology:
- "Virt driver guest vCPU topology configuration" (https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology)
- "Virt driver guest NUMA node placement & topology" (https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement)
- "Virt driver large page allocation for guest RAM" (https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages)
- May need support to prevent 'noisy neighbours' stealing L3 cache - unproven, and no blueprint we're aware of.
- To optimize data rate we need to keep all working data in L3 cache:
- High availability:
- Requires anti-affinity rules to prevent active/passive being instantiated on same host - already supported, so no gap.
- Elastic scaling:
- Readily achievable using existing features - no gap.
- VLAN trunking:
- "VLAN trunking networks for NFV" (https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks et al).
- Other:
- Being able to offer apparent traffic separation (e.g. service traffic vs. application management) over single network is also useful in some cases.
- "Support two interfaces from one VM attached to the same network" (https://blueprints.launchpad.net/nova/+spec/multiple-if-1-net)
- Being able to offer apparent traffic separation (e.g. service traffic vs. application management) over single network is also useful in some cases.
Virtual IMS Core
Contributed by: Calum Loudon
Description
Project Clearwater, http://www.projectclearwater.org/. An open source implementation of an IMS core designed to run in the cloud and be massively scalable. It provides SIP-based call control for voice and video as well as SIP-based messaging apps. As an IMS core it provides P/I/S-CSCF function together with a BGCF and an HSS cache, and includes a WebRTC gateway providing interworking between WebRTC & SIP clients.
Characteristics relevant to NFV/OpenStack
- Mainly a compute application: modest demands on storage and networking.
- Fully HA, with no SPOFs and service continuity over software and hardware failures; must be able to offer SLAs.
- Elastically scalable by adding/removing instances under the control of the NFV orchestrator.
Requirements
- Compute application:
- OpenStack already provides everything needed; in particular, there are no requirements for an accelerated data plane, nor for core pinning nor NUMA
- HA:
- implemented as a series of N+k compute pools; meeting a given SLA requires being able to limit the impact of a single host failure
- potentially a scheduler gap here: affinity/anti-affinity can be expressed pair-wise between VMs, which is sufficient for a 1:1 active/passive architecture, but an N+k pool needs a concept equivalent to "group anti-affinity" i.e. allowing the NFV orchestrator to assign each VM in a pool to one of X buckets, and requesting OpenStack to ensure no single host failure can affect more than one bucket
- (there are other approaches which achieve the same end e.g. defining a group where the scheduler ensures every pair of VMs within that group are not instantiated on the same host)
- for study whether this can be implemented using current scheduler hints
- Elastic scaling:
- as for compute requirements there is no gap - OpenStack already provides everything needed.
References:
- Network Functions Virtualization NFV Performance & Portability Best Practices - DRAFT
- ETSI-NFV Use Cases V1.1.1 [2]
Related Teams and Projects
- OpenStack Congress - Policy as a Service [3]
Development Efforts
Active Bugs
Add the "nfv" tag to bugs to have them appear in these queries:
- Nova: https://bugs.launchpad.net/nova/+bugs?field.tag=nfv
- Neutron: https://bugs.launchpad.net/neutron/+bugs?field.tag=nfv
Active Blueprints
The NFV use case mappings identified below are from the perspective of higher performing use cases. Please note that there are many possible configurations of devices for each of these use cases and it is not implied that they will all need the proposed capability in the relevant blueprint.
There is an automatically updated gerrit dashboard for all specs and code under review here: http://nfv.russellbryant.net
PRIORITY - repeatedly mentioned at the BOF as blockers:
Description | Project(s) | Status | Blueprint(s) | Design(s) | ETSI-NFV Use Cases |
---|---|---|---|---|---|
Support two interfaces from one VM attached to the same network | Nova | first BP submit | https://blueprints.launchpad.net/nova/+spec/multiple-if-1-net | https://review.openstack.org/97716 https://review.openstack.org/98488 (patch?) |
|
VLAN trunking networks for NFV
This line item now confuses various requirements together: VLAN tagged traffic transmissible over a tenant network is the most important (even if Openstack is otherwise VLAN unaware) decomposition of VLAN trunks to virtual networks VLAN tagged traffic to a physical appliance management of VLANs on ports as sub-ports (nice to have, not a blocker) |
Neutron | first BP submit | https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks (tenant trunking)
https://blueprints.launchpad.net/neutron/+spec/l2-gateway (physical appliance-specific decomposition) https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms (VLAN port management) |
https://review.openstack.org/#/c/100278/ (physical appliance-specific decomposition)
https://review.openstack.org/97714 (tenant trunking) https://review.openstack.org/#/c/94612/ (subports) https://review.openstack.org/#/c/92541/ (patch for subports) |
* #1 is a broadly applicable IaaS requirement.
|
Permit unaddressed interfaces for NFV use cases | Neutron | first BP submit | https://blueprints.launchpad.net/neutron/+spec/nfv-unaddressed-interfaces https://blueprints.launchpad.net/neutron/+spec/ml2-ovs-portsecurity | https://review.openstack.org/97715 https://review.openstack.org/#/c/99873/ |
|
The rest:
neutron port enhancement related to servicevm is summarized at https://wiki.openstack.org/wiki/ServiceVM/neutron-port-attributes
Description | Project(s) | Status | Blueprint(s) | Design(s) | ETSI-NFV Use Cases |
---|---|---|---|---|---|
SR-IOV Networking Support | Nova | Design Approved | https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov | https://review.openstack.org/#/c/86606/ |
|
Support for NUMA and VCPU topology configuration | https://blueprints.launchpad.net/nova/+spec/nova-virt-numa-and-vcpu-topology |
| |||
|
Nova | Design Approved | https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology | https://review.openstack.org/93510 |
|
|
Nova | Design review Approved | https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement | https://review.openstack.org/93636 |
|
|
Nova | Design review in progress | https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages | https://review.openstack.org/93653 |
|
|
Nova | Design review in progress | https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning | https://review.openstack.org/93652 |
|
|
Nova | Design Approved | https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling | https://review.openstack.org/#/c/100871/ |
|
Soft affinity support for server groups | Nova | Design review in progress | https://blueprints.launchpad.net/nova/+spec/soft-affinity-for-server-group | https://review.openstack.org/91328 |
|
Open vSwitch-based Security Groups: Open vSwitch Implementation of FirewallDriver | Neutron | Design review in progress | https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver | https://review.openstack.org/89712 |
|
Framework for Advanced Services in Virtual Machines | Neutron | https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms |
| ||
Neutron Services Insertion, Chaining, and Steering | Neutron | Approved | https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering | https://review.openstack.org/93524 |
NOTE: this service chaining BP is all about chaining aaS services, not chaining tenant NFVs. Is this the one we want or do we require a new BP?
|
Schedule vms per flavour cpu overcommit | Nova | Design review in progress | https://blueprints.launchpad.net/nova/+spec/flavor-cpu-overcommit | https://review.openstack.org/88286 |
|
OVF Meta-Data Import via Glance | Glance | Design review in progress | https://blueprints.launchpad.net/glance/+spec/epa-ovf-meta-data-import | https://review.openstack.org/#/c/104904/ |
|
Support for high performance Intel(R) Data Plane Development Kit based vSwitches | |||||
|
Neutron | Design review in progress | https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use | https://review.openstack.org/96183 |
|
|
Nova | Design review in progress | https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost | https://review.openstack.org/95805 |
|
NIC state aware scheduling | Nova | Rejected | https://blueprints.launchpad.net/nova/+spec/nic-state-aware-scheduling | https://review.openstack.org/87978 |
|
Add PCI and PCIe device capability aware scheduling | Nova | Abandoned | https://blueprints.launchpad.net/nova/+spec/pci-device-capability-aware-scheduling | https://review.openstack.org/92843 |
|
Snabb NFV mechanism driver | Neutron | Design review in progress | https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver | https://review.openstack.org/95711 |
|
VIF_VHOSTUSER (qemu vhost-user) support | Nova | Submitted w/ code | https://blueprints.launchpad.net/nova/+spec/vif-vhostuser | https://review.openstack.org/96138 |
|
Solver Scheduler - complex constraints scheduler with NFV use cases | Nova | Design review in progress | https://blueprints.launchpad.net/nova/+spec/solver-scheduler | https://review.openstack.org/#/c/96543/ |
|
Discless VM | Nova | Under discussion | https://blueprints.launchpad.net/nova/+spec/libvirt-empty-vm-boot-pxe |
| |
Network QoS API | Neutron | Under discussion | https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api | https://review.openstack.org/#/c/88599 |
|
Persist scheduler hints | Nova | Design review in progress | https://blueprints.launchpad.net/nova/+spec/persist-scheduler-hints | https://review.openstack.org/#/c/88983/ |
|
Port mirroring | Neutron | Under discussion | https://blueprints.launchpad.net/neutron/+spec/port-mirroring |
| |
Traffic Steering Abstraction | Neutron | Design review in progress | https://blueprints.launchpad.net/neutron/+spec/traffic-steering-abstraction | https://review.openstack.org/92477/ |
|
Evacuate instance to scheduled host | Nova | Needs code review | https://blueprints.launchpad.net/nova/+spec/find-host-and-evacuate-instance | https://review.openstack.org/84429 | |
Extensible resource tracker (dependency of other work) | Nova | Design Approved | https://blueprints.launchpad.net/nova/+spec/extensible-resource-tracking | https://review.openstack.org/#/c/86050/ |