Open Stack

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.

Just so we're all on the same page, in what cases is dhcp/ra not
appropriate?

Cheers,
Dan

On Feb 25, 2011 7:11 AM, "Trey Morris" <trey.morris at rackspace.com> wrote:
> definitely not fine to use dhcp in all cases.
>
> On Thu, Feb 24, 2011 at 3:28 AM, Dan Mihai Dumitriu <dmd17 at cornell.edu
>wrote:
>
>> If we can dynamically plug (and presumably unplug) a vNIC into a
>> vPort, and assign the IP at that time, does that imply that we cannot
>> use the IP injection into the VM image? Is it fine to use DHCP or RA
>> in all cases?
>>
>>
>> On Wed, Feb 23, 2011 at 22:29, Ishimoto, Ryu <ryu at midokura.jp> wrote:
>> >
>> > Hi everyone,
>> > I have been following the discussion regarding the new 'pluggable'
>> network
>> > service design, and wanted to drop in my 2 cents ;-)
>> > 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.
>> > 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.
>> > 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:
>> > 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.
>> > 2. Create a vNIC
>> > 3. Plug a vNIC into an avaiable vPort. In this case it just means
>> mapping
>> > this vNIC to an unused IP address.
>> > 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.
>> > 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.
>> > 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.
>> > 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.
>> > Please let me know if all this made any sense. :-) Would love to get
>> some
>> > feedbacks.
>> > Regards,
>> > Ryu Ishimoto
>> >
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to : openstack at lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help : https://help.launchpad.net/ListHelp
>> >
>> >
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>
>
> Confidentiality Notice: This e-mail message (including any attached or
> embedded documents) is intended for the exclusive and confidential use of
the
> individual or entity to which this message is addressed, and unless
otherwise
> expressly indicated, is confidential and privileged information of
Rackspace.
> Any dissemination, distribution or copying of the enclosed material is
prohibited.
> If you receive this transmission in error, please notify us immediately by
e-mail
> at abuse at rackspace.com, and delete the original message.
> Your cooperation is appreciated.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110225/37997700/attachment.html>