During the course of discussions at the diablo summit in Santa Clara, several topics were discussed and recognized as valuable, but we decided not to attempt to achieve them as part of the development in the diablo time-frame.
This blueprint is intended to capture several of those issues. These issue may grow to be their own development blueprints, in which case we should link to those blueprints from this page.
How should knowledge of the network topology and resources/capacity be used to influence workload placement decisions by the scheduler? Consensus was that the schedule within nova needed to be able to take advantage of data about the network. Two example use cases:
- Network isolation is being performed using VLANs, so all VMs attached to a particular "network" must be placed in the same data center pod.
- End-to-end QoS guarantees need to be provided between VMs. How to make sure that VMs are placed in a location that can satisfy this request?
Standard APIs for Higher-Level Services
While Quantum is currently focused on basic L2 connectivity with more advanced functionality being provided via API extensions, there was agreement that our long term goal was to define base APIs for higher level functionality, including L3 connectivity, ACLs, and QoS (to name a few). Currently, different plugins are free to provide this functionality via extensions. These extension will provide concrete proposals for what may become "base" APIs based on decisions made at future design summits.
Exposing Attributes of the Physical Network via the Logical Network API
An interesting question was raised about how the logical network model could deal with information about properties of the physical network. For example, could a customer determine whether logical networks were implemented using a redundant physical network?