openstack team mailing list archive

[Trey Morris <trey.morris@xxxxxxxxxxxxx>]

There can be reconfiguration of the network, just not adding/removing of
vifs. The addition of a new vif would generally only be done if an
additional nic or bridge was added to the host. I figure this to be a rare
occurrence. You can add or remove IPs to/from an instance by configuring
aliases on existing vifs (which the agent will do). Biggest case I can think
of where dhcp is not appropriate: service providers.

On Thu, Feb 24, 2011 at 6:49 PM, Dan Mihai Dumitriu <dmd17@xxxxxxxxxxx>wrote:

> 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@xxxxxxxxxxxxx> wrote:
> > definitely not fine to use dhcp in all cases.
> >
> > On Thu, Feb 24, 2011 at 3:28 AM, Dan Mihai Dumitriu <dmd17@xxxxxxxxxxx
> >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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> >> > Unsubscribe : https://launchpad.net/~openstack
> >> > More help : https://help.launchpad.net/ListHelp
> >> >
> >> >
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> >> 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@xxxxxxxxxxxxx, and delete the original message.
> > Your cooperation is appreciated.
> >
>
>


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@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.