Difference between revisions of "Obsolete:NetworkUsecases"
| Line 26: | Line 26: | ||
== Network Flows == | == Network Flows == | ||
| − | This is an attempt to diagram possible flows between the network services and a service like Nova that may consume this. This is put up as a strawman to consider. The goal is to narrow down the possible flows so that when these independent services are built they interact based on an agreed to model. Again, this is a strawman discussion can take place at: | + | This is an attempt to diagram possible flows between the network services and a service like Nova that may consume this. This is put up as a strawman to consider. The goal is to narrow down the possible flows so that when these independent services are built they interact based on an agreed to model. |
| + | |||
| + | [[attachment:NetworkFlows.pdf]] | ||
| + | |||
| + | Again, this is a strawman discussion can take place at: | ||
[http://etherpad.openstack.org/network-flows Network Flows Etherpad discussion] | [http://etherpad.openstack.org/network-flows Network Flows Etherpad discussion] | ||
Revision as of 22:24, 24 May 2011
The goal here is to agree on a set of increasingly sophisticated OpenStack networking use cases that we can use as milestones to track our progress during the Diablo period.
While some use cases involve dependencies on other network projects, we can start out by defining them on a per-project basis. Dependencies on other project should be called out when possible.
Quantum
- Milestone 0: create/delete networks, create/delete ports, attach/detach interfaces via CLI API client
- requires api core, api auth, core daemon, abstract plugin, cli API client, and a simple "fake" plugin.
- Milestone 1: Ability to replicate nova's flat or vlan using CLI API client.
- requires Milestone 0, plus integration with nova, and at least one "real" open-source plugin.
- does not require multi-nic in nova, api extensions, client gui.
- Note: makes no assumption about how IP addresses are assigned to VMs.
- Note: vlan model will not provide NAT gateway, as currently is the case with nova.
- Milestone 2: GUI demo of Milestone 1
- requires Milestone 1 and GUI client
- Milestone 3: Integrate with a non-nova "external service".
- requires milestone 1, plus an available non-nova service.
- DHCP service from Melange seems like a good candidate if it is ready.
- Note: this could also service as an early "multi-service" container use case for donabe.
- Ideally, we would have a GUI that could configure "instances" of the other service as well.
- Milestone 4: Demonstrate API Extension
- requires API extension work, plus at least one open-source plugin that exposes an extension.
- Milestone 5: Multi-tier application
- requires milestone 1, plus multi-nic in nova.
Network Flows
This is an attempt to diagram possible flows between the network services and a service like Nova that may consume this. This is put up as a strawman to consider. The goal is to narrow down the possible flows so that when these independent services are built they interact based on an agreed to model.
attachment:NetworkFlows.pdf
Again, this is a strawman discussion can take place at:
