<p>So in cases where static injection into the image is used, it seems there can be no dynamic reconfiguration of the network, ie cannot plug a vNic into a network after the VM is started.</p>
<p>Just so we're all on the same page, in what cases is dhcp/ra not appropriate?</p>
<p>Cheers,<br>
Dan<br>
</p>
<p>On Feb 25, 2011 7:11 AM, "Trey Morris" <<a href="mailto:trey.morris@rackspace.com">trey.morris@rackspace.com</a>> wrote:<br type="attribution">> definitely not fine to use dhcp in all cases.<br>> <br>
> On Thu, Feb 24, 2011 at 3:28 AM, Dan Mihai Dumitriu <<a href="mailto:dmd17@cornell.edu">dmd17@cornell.edu</a>>wrote:<br>> <br>>> If we can dynamically plug (and presumably unplug) a vNIC into a<br>>> vPort, and assign the IP at that time, does that imply that we cannot<br>
>> use the IP injection into the VM image?  Is it fine to use DHCP or RA<br>>> in all cases?<br>>><br>>><br>>> On Wed, Feb 23, 2011 at 22:29, Ishimoto, Ryu <<a href="mailto:ryu@midokura.jp">ryu@midokura.jp</a>> wrote:<br>
>> ><br>>> > Hi everyone,<br>>> > I have been following the discussion regarding the new 'pluggable'<br>>> network<br>>> > service design, and wanted to drop in my 2 cents ;-)<br>
>> > Looking at the current implementation of Nova, there seems to be a very<br>>> > strong coupling between compute and network services.  That is, tasks<br>>> that<br>>> > are done by the network service are executed at the time of VM<br>
>> > instantiation, making the compute code dependent on the network service,<br>>> and<br>>> > vice versa.  This dependency seems undesirable to me as it adds<br>>> restrictions<br>>> > to implementing 'pluggable' network services, which can vary, with many<br>
>> ways<br>>> > to implement them.<br>>> > Would anyone be opposed to completely separating out the network service<br>>> > logic from compute?  I don't think it's too difficult to accomplish this,<br>
>> > but to do so, it will require that the network service tasks, such as IP<br>>> > allocation, be executed by the user prior to instantiating the VM.<br>>> > In the new network design(from what I've read up so far), there are<br>
>> concepts<br>>> > of vNICs, and vPorts, where vNICs are network interfaces that are<br>>> associated<br>>> > with the VMs, and vPorts are logical ports that vNICs are plugged into<br>>> for<br>
>> > network connectivity.  If we are to decouple network and compute<br>>> services,<br>>> > the steps required for FlatManager networking service would look<br>>> something<br>>> > like:<br>
>> > 1. Create ports for a network.  Each port is associated with an IP<br>>> address<br>>> > in this particular case, since it's an IP-based network.<br>>> > 2. Create a vNIC<br>>> > 3. Plug a vNIC into an avaiable vPort.  In this case it just means<br>
>> mapping<br>>> > this vNIC to an unused IP address.<br>>> > 4. Start a VM with this vNIC.  vNIC is already mapped to an IP address,<br>>> so<br>>> > compute does not have to ask the network service to do any IP allocation.<br>
>> > In this simple example, by removing the request for IP allocation from<br>>> > compute, the network service is no longer needed during the VM<br>>> > instantiation.  While it may require more steps for the network setup in<br>
>> > more complex cases, it would still hold true that, once the vNIC and<br>>> vPort<br>>> > are mapped, compute service would not require any network service during<br>>> the<br>>> > VM instantiation.<br>
>> > IF there is still a need for the compute to access the network service,<br>>> > there is another way.  Currently, the setup of the network<br>>> > environment(bridge, vlan, etc) is all done by the compute service. With<br>
>> the<br>>> > new network model, these tasks should either be separated out into a<br>>> > standalone service('network agent') or at least be separated out into<br>>> > modules with generic APIs that the network plugin providers can<br>
>> implement.<br>>> >  By doing so, and if we can agree on a rule that the compute service must<br>>> > always go through the network agent to access the network service, we can<br>>> > still achieve the separation of compute from network services.   Network<br>
>> > agents should have full access to the network service as they are both<br>>> > implemented by the same plugin provider.  Compute would not be aware of<br>>> the<br>>> > network agent accessing the network service.<br>
>> > With this design, the network service is only tied to the network REST<br>>> API<br>>> > and the network agent, both of which are implemented by the plugin<br>>> > providers.  This would allow them to implement their network service<br>
>> without<br>>> > worrying about the details of the compute service.<br>>> > Please let me know if all this made any sense. :-)  Would love to get<br>>> some<br>>> > feedbacks.<br>>> > Regards,<br>
>> > Ryu Ishimoto<br>>> ><br>>> > _______________________________________________<br>>> > Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>
>> > Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>>> > Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>
>> > More help   : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br>>> ><br>>> ><br>>><br>>> _______________________________________________<br>
>> Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>>> Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>>> Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a><br>
>> More help   : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a><br>>><br>> <br>> <br>> Confidentiality Notice: This e-mail message (including any attached or<br>
> embedded documents) is intended for the exclusive and confidential use of the<br>> individual or entity to which this message is addressed, and unless otherwise<br>> expressly indicated, is confidential and privileged information of Rackspace.<br>
> Any dissemination, distribution or copying of the enclosed material is prohibited.<br>> If you receive this transmission in error, please notify us immediately by e-mail<br>> at <a href="mailto:abuse@rackspace.com">abuse@rackspace.com</a>, and delete the original message.<br>
> Your cooperation is appreciated.<br>> <br></p>