<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>I agree, this is exactly where we want to take the network services for OpenStack. The goal should be to decouple Compute from Network, with an eye toward a project separation post-Cactus (this should have a lot of discussion at the next design summit). For Cactus we have explicitly kept the network manager (and the volume manager) inside of Nova in order to minimize risk to stability for this release. For Diablo I think we need to identify any of the dependencies and touchpoints that Compute has on Network and make a clean separation. Ryu Ishimoto has made a good first step, we need to identify any issues with all the possible network configurations.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Following up on the other big networking thread, I would like to see a project schema that includes the core networking API, network manager/controller, and plug-in interfaces. Additionally, we should identify the “sub-projects” that can be optional networking components (such as VPN, DHCP, etc.).<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Separate from networking we need to do the same exercise for the volume manager and block storage systems.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'>John<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:black'><o:p> </o:p></span></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> openstack-bounces+john=openstack.org@lists.launchpad.net [mailto:openstack-bounces+john=openstack.org@lists.launchpad.net] <b>On Behalf Of </b>Dan Wendlandt<br><b>Sent:</b> Wednesday, February 23, 2011 7:49 AM<br><b>To:</b> Ishimoto, Ryu<br><b>Cc:</b> openstack@lists.launchpad.net<br><b>Subject:</b> Re: [Openstack] Decoupling of Network and Compute services for the new Network Service design<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I think this is very much inline with what we've been thinking. To me, providing a clean and generic programming interface that decouples the network functionality from the existing nova stack is a first step in creating a standalone network service. <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Also, I am not sure if this is implied by step #3 below, but it seems that the compute and network service will need to share some identifier so that the network entity running on the compute node can "recognize" a VM interface and associate it with a vPort. For example, each vNIC has an identifier assigned by the compute service, a call to the network service associates that vNIC id with a vPort, and when the compute node creates a device (e.g., tap0), it tells the network plugin on the host the vNIC id for that device (there are several other possible variations on this theme...). In your example below this may not be strictly required because all vNICs get connected to the same network, but in a general model for a network service this will be required. <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>dan<o:p></o:p></p><div><p class=MsoNormal>On Wed, Feb 23, 2011 at 5:29 AM, Ishimoto, Ryu <<a href="mailto:ryu@midokura.jp" target="_blank">ryu@midokura.jp</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Hi everyone,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I have been following the discussion regarding the new 'pluggable' network service design, and wanted to drop in my 2 cents ;-)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Looking at the current implementation of Nova, there seems to be a very strong coupling between compute and network services. That is, tasks that are done by the network service are executed at the time of VM instantiation, making the compute code dependent on the network service, and vice versa. This dependency seems undesirable to me as it adds restrictions to implementing 'pluggable' network services, which can vary, with many ways to implement them.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Would anyone be opposed to completely separating out the network service logic from compute? I don't think it's too difficult to accomplish this, but to do so, it will require that the network service tasks, such as IP allocation, be executed by the user prior to instantiating the VM. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In the new network design(from what I've read up so far), there are concepts of vNICs, and vPorts, where vNICs are network interfaces that are associated with the VMs, and vPorts are logical ports that vNICs are plugged into for network connectivity. If we are to decouple network and compute services, the steps required for FlatManager networking service would look something like:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>1. Create ports for a network. Each port is associated with an IP address in this particular case, since it's an IP-based network.<o:p></o:p></p></div><div><p class=MsoNormal>2. Create a vNIC<o:p></o:p></p></div><div><p class=MsoNormal>3. Plug a vNIC into an avaiable vPort. In this case it just means mapping this vNIC to an unused IP address.<o:p></o:p></p></div><div><p class=MsoNormal>4. Start a VM with this vNIC. vNIC is already mapped to an IP address, so compute does not have to ask the network service to do any IP allocation. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In this simple example, by removing the request for IP allocation from compute, the network service is no longer needed during the VM instantiation. While it may require more steps for the network setup in more complex cases, it would still hold true that, once the vNIC and vPort are mapped, compute service would not require any network service during the VM instantiation.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>IF there is still a need for the compute to access the network service, there is another way. Currently, the setup of the network environment(bridge, vlan, etc) is all done by the compute service. With the new network model, these tasks should either be separated out into a standalone service('network agent') or at least be separated out into modules with generic APIs that the network plugin providers can implement. By doing so, and if we can agree on a rule that the compute service must always go through the network agent to access the network service, we can still achieve the separation of compute from network services. Network agents should have full access to the network service as they are both implemented by the same plugin provider. Compute would not be aware of the network agent accessing the network service.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>With this design, the network service is only tied to the network REST API and the network agent, both of which are implemented by the plugin providers. This would allow them to implement their network service without worrying about the details of the compute service.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Please let me know if all this made any sense. :-) Would love to get some feedbacks.<o:p></o:p></p></div><div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Regards,<o:p></o:p></p></div><div><p class=MsoNormal>Ryu Ishimoto<o:p></o:p></p></div></div><div><p class=MsoNormal><span style='color:#888888'><o:p> </o:p></span></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><br>_______________________________________________<br>Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>Post to : <a href="mailto:openstack@lists.launchpad.net" target="_blank">openstack@lists.launchpad.net</a><br>Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><br><br clear=all><br>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <br>Nicira Networks, Inc. <br><a href="http://www.nicira.com" target="_blank">www.nicira.com</a> | <a href="http://www.openvswitch.org" target="_blank">www.openvswitch.org</a><br>Sr. Product Manager <br>cell: 650-906-2650<br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<o:p></o:p></p></div></div></div></body></html>