Difference between revisions of "NetworkServiceDiablo"
Line 16: | Line 16: | ||
(diagram goes here) | (diagram goes here) | ||
− | == Nova Refactoring and Responsibilities == | + | == Network Services Actors == |
+ | |||
+ | === Nova Refactoring and Responsibilities === | ||
It is proposed that Nova networking be refactored in two ways: | It is proposed that Nova networking be refactored in two ways: | ||
# Combine networking capabilities in a more contained model, but '''do not''' remove support for existing options | # Combine networking capabilities in a more contained model, but '''do not''' remove support for existing options | ||
# Add support for the Virtual Network Service to the existing flat (static), flat (DHCP), and VLAN options | # Add support for the Virtual Network Service to the existing flat (static), flat (DHCP), and VLAN options | ||
− | == Virtual Networking Service == | + | === Virtual Networking Service === |
(This project needs a name. "Quantum" was proposed.) | (This project needs a name. "Quantum" was proposed.) | ||
− | The Virtual Networking Service will have the following responsiblities: | + | The Virtual Networking Service will have the following responsiblities for Diablo: |
# Provide API for managing L2 network abstraction (“virtual networks”?) | # Provide API for managing L2 network abstraction (“virtual networks”?) | ||
# Provide authentication, verification, etc | # Provide authentication, verification, etc | ||
Line 32: | Line 34: | ||
# Resource consumption look-up service | # Resource consumption look-up service | ||
# Plug-in capability directory | # Plug-in capability directory | ||
+ | |||
+ | === Virtual Networking Service Plug-in === | ||
+ | Plug-ins to the VNS will have the following responsibilities for Diablo: | ||
+ | # Receive and verify requests from L2 Service | ||
+ | # Map logical abstractions to actual physical/virtual service implementation/configuration | ||
+ | # Advertise capabilities to L2 Service | ||
+ | |||
+ | === IPAM Service === | ||
+ | TBD | ||
+ | |||
+ | === IPAM Servcie Plug-in === | ||
+ | TBD | ||
+ | |||
+ | === Container Service === | ||
+ | The container service (if targeted in Diablo timeframe) will: | ||
+ | # Provide an API for managing a container abstraction | ||
+ | #* Container represents a logical group of resources to be managed as a unit | ||
+ | #* Initial focus to be on networks and net services | ||
+ | # Provide catalog of container “flavors” | ||
+ | # Provide way to define container “flavors” | ||
+ | # Provide way to instantiate instance of container “flavor” | ||
+ | # Provide way to build container definition dynamically | ||
+ | # Provide mechanism for modifying container instance at run-time. | ||
+ | # Decompose request an communicate with other network services as required. | ||
+ | |||
+ | == Virtual Network Components == | ||
+ | |||
+ | === Network Segment === |
Revision as of 06:38, 28 April 2011
Network Service Proposal for Diablo
Overview
This proposal is the result of discussions between several community members that had independently submitted blueprints for networking capabilities in Openstack. Those proposals included:
(List proposals here)
This page describes the resulting target services to be delivered in experiemental form in the Diablo timeframe.
Network Services Model
The diagram below describes two things:
- The software services architecture, and the relationship of the Virtual Network Service and IPAM Service to Nova
- The logical network architecture elements used to describe a virtual network topology in the Diablo timeframe
(diagram goes here)
Network Services Actors
Nova Refactoring and Responsibilities
It is proposed that Nova networking be refactored in two ways:
- Combine networking capabilities in a more contained model, but do not remove support for existing options
- Add support for the Virtual Network Service to the existing flat (static), flat (DHCP), and VLAN options
Virtual Networking Service
(This project needs a name. "Quantum" was proposed.)
The Virtual Networking Service will have the following responsiblities for Diablo:
- Provide API for managing L2 network abstraction (“virtual networks”?)
- Provide authentication, verification, etc
- Provide error handling
- Decompose request (if necessary)
- Dispatch requests to appropriate plug-in(s)
- Resource consumption look-up service
- Plug-in capability directory
Virtual Networking Service Plug-in
Plug-ins to the VNS will have the following responsibilities for Diablo:
- Receive and verify requests from L2 Service
- Map logical abstractions to actual physical/virtual service implementation/configuration
- Advertise capabilities to L2 Service
IPAM Service
TBD
IPAM Servcie Plug-in
TBD
Container Service
The container service (if targeted in Diablo timeframe) will:
- Provide an API for managing a container abstraction
- Container represents a logical group of resources to be managed as a unit
- Initial focus to be on networks and net services
- Provide catalog of container “flavors”
- Provide way to define container “flavors”
- Provide way to instantiate instance of container “flavor”
- Provide way to build container definition dynamically
- Provide mechanism for modifying container instance at run-time.
- Decompose request an communicate with other network services as required.