MoveIpAllocation - Revision history

Fifieldt at 09:48, 19 December 2013

2013-12-19T09:48:29Z

Ryan Lane: Text replace - "NovaSpec" to "NovaSpec"

2013-02-17T23:31:07Z

Text replace - "NovaSpec" to "NovaSpec"

Ryan Lane: Text replace - "NOTOC" to ""

2013-02-17T23:29:47Z

Text replace - "__NOTOC__" to ""

Clark Boylan at 22:14, 16 February 2013

2013-02-16T22:14:22Z

VishvanandaIshaya at 16:27, 2 November 2010

2010-11-02T16:27:53Z

VishvanandaIshaya at 18:05, 1 November 2010

2010-11-01T18:05:10Z

VishvanandaIshaya at 18:03, 1 November 2010

2010-11-01T18:03:54Z

VishvanandaIshaya at 06:39, 1 November 2010

2010-11-01T06:39:05Z

VishvanandaIshaya at 06:38, 1 November 2010

2010-11-01T06:38:12Z

VishvanandaIshaya at 06:29, 1 November 2010

2010-11-01T06:29:58Z

@@ Line 1: / Line 1: @@
+{{OldDesignPage}}
 * '''Launchpad Entry''': NovaSpec:move-ip-allocation
 * '''Created''': 10/31/10

@@ Line 1: / Line 1: @@
-* '''Launchpad Entry''': [[NovaSpec]]:move-ip-allocation
+* '''Launchpad Entry''': NovaSpec:move-ip-allocation
 * '''Created''': 10/31/10
 * '''Contributors''': Vish Ishaya

@@ Line 1: / Line 1: @@
-__NOTOC__
 * '''Launchpad Entry''': [[NovaSpec]]:move-ip-allocation
 * '''Created''': 10/31/10

@@ Line 27: / Line 27: @@
 Currently, there are three strategies for networking, implemented by different managers:
-[[FlatManager]] -- ip addresses are grabbed from a network and injected into the image on launch.  All instances are attached to the same manually configured bridge.
+FlatManager -- ip addresses are grabbed from a network and injected into the image on launch.  All instances are attached to the same manually configured bridge.
 FlatDHCPManager -- ip addresses are grabbed from a network, and a single bridge is created for all instances. A dhcp server is started to pass out addresses
-[[VlanManager]] -- each project gets its own vlan, bridge and network.  A dhcpserver is started for each vlan, and all instances are bridged into that vlan.
+VlanManager -- each project gets its own vlan, bridge and network.  A dhcpserver is started for each vlan, and all instances are bridged into that vlan.
 The implementation of creating bridges, vlans, dhcpservers, and firewall rules is done by the driver linux_net.  This layer of abstraction is so that we can at some point support configuring hardware switches etc. using the same managers.
-My goal with the Manager refactor was to move all of the code relating to each component into the Manager classes.  For example, all code relating to networks/ips would be done by [[NetworkManager]].  That said, code relating to businesss objects needs to be run by three separate workers, and not all of it has been encapsulated in the manager.  For example, the initial creation of the record for instances/volumes is done  by nova-api by hitting the db directly instead of using a method on the manager.
+My goal with the Manager refactor was to move all of the code relating to each component into the Manager classes.  For example, all code relating to networks/ips would be done by NetworkManager.  That said, code relating to businesss objects needs to be run by three separate workers, and not all of it has been encapsulated in the manager.  For example, the initial creation of the record for instances/volumes is done  by nova-api by hitting the db directly instead of using a method on the manager.
 Here is some horrible ascii art of what each component does during run instance. The manager's methods are called directly for local setup, and they are called via rpc to nova-network which runs the manager wrapped by a service which exposes public methods to rpc. The *d items aren't specifically related to networking but help make it clear when things occur
@@ Line 100: / Line 100: @@
 === Proof of Concept ===
-At least one implementation using a different networking model should be tried.  Either [[FlatNetwork]] can be modified to allocate ips from a network associated with the host instead of a project, or a new networking model can be created to support clusters and one network per cluster.
+At least one implementation using a different networking model should be tried.  Either FlatNetwork can be modified to allocate ips from a network associated with the host instead of a project, or a new networking model can be created to support clusters and one network per cluster.
 === Migration ===

@@ Line 6: / Line 6: @@
 == Summary ==
-Ip allocation currently occurs at the api layer.  This is not the best place for ip allocation to occur because it forces the api to know to much about the topology of the network.
+Ip allocation currently occurs at the api layer.  This is not the best place for ip allocation to occur because it forces the api to know to much about the topology of the network.  This spec is most likely a precursor to [[VirtualNetworks]].
 == Release Note ==

@@ Line 96: / Line 96: @@
 == Implementation ==
-The implementation itself should be fairly straightforward.  It means moving the calls to network to compute manager.  At least one implementation using a different networking model should be tried.  Either [[FlatNetwork]] can be modified to allocate ips from a network associated with the host instead of a project, or a new networking model can be created to support clusters and one network per cluster.
+The implementation itself should be fairly straightforward.  It means moving the calls to network to compute manager.
 === Migration ===

@@ Line 1: / Line 1: @@
 __NOTOC__
-= Placeholder Spec =
+* '''Launchpad Entry''': [[NovaSpec]]:move-ip-allocation
-The current architecture of networking in nova and why the allocation should be moved was explained in an email that has been included below.  This is a small change that could be considered a part of the spec for [[VirtualNetworks]]
+== Summary ==
-= Current =
+Ip allocation currently occurs at the api layer.  This is not the best place for ip allocation to occur because it forces the api to know to much about the topology of the network.
 Currently, there are three strategies for networking, implemented by different managers:
@@ Line 43: / Line 63: @@
 This all works and allows us to return an ip very quickly from an api call, but it does have some issues.  Most importantly, in some network models, the api server may not have enough information to know how to allocate an ip.  For example, in the flat mode, we may want to have a cluster of compute nodes associated with a particular network host, and get_network returns a network based on the compute host instead of the project as we do in vlan mode.
-= Future (IMO) =
+=== New Implementation ===
-I think we should move the allocating of the ip further down the stack like so:
+The allocation of the ip should move further down the stack like so:
 <pre><nowiki>
@@ Line 73: / Line 93: @@
 </nowiki></pre>
-= Floating Ips =
+== Implementation ==
-The floating ip allocation is simpler and rarer, so we actually just to a simple call through the queue and all of the setup is done by nova-network.  It is important to note that floating ips are associated with fixed ips, not instances directly, and more than one floating ip can be associated with each fixed ip.  They are implemented with iptables forwarding rules.
+At some point, it would be useful to have some kind of webhook that can be specified so that end-users have an alternative to constantly polling the api system.  Webhooks are useful for more than just ip allocation, so they should be addressed in a separate blueprint
-= Security Groups =
+== BoF agenda and discussion ==
-Soren did the security group code, so I'll let him do an overview.  They are implemented on the host level.  I have a couple patches I need to submit to speed them up and to allow intra-project communication in vlan mode.
+Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
 ----
 [[Category:Spec]]

← Older revision		Revision as of 06:29, 1 November 2010
Line 81:		Line 81:
	Soren did the security group code, so I'll let him do an overview. They are implemented on the host level. I have a couple patches I need to submit to speed them up and to allow intra-project communication in vlan mode.		Soren did the security group code, so I'll let him do an overview. They are implemented on the host level. I have a couple patches I need to submit to speed them up and to allow intra-project communication in vlan mode.

−	~~<code><nowiki>~~[[Category:Spec]]~~</nowiki></code>~~	+	[[Category:Spec]]