On Feb 24, 2011, at 2:02 PM, Eric Day wrote:
I agree with Vish, I think the correct approach is 3. I have some
ideas on terminology and how to think about this. A scheduler
should not be it's own top-level service. It should instead be a
plugin point (more like auth or db). It would plug into
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
Hi Ed,
So it sounds like we're all talking about the same thing, we just need
to start a Nova glossary so we're all on the smae page of what terms
mean. :) So it sounds like from my last email, kernel == scheduler,
and scheduler == best match.
I'm not too concerned about naming of things as
I see, the latency of setting up bridges and vlans could be a problem.
How about the second problem, that of not having enough information to
assign the IP. Is it really necessary to know what physical node the
VM will run on before assigning the IP? Shouldn't that be decoupled?
For example, if
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 r...@midokura.jp wrote:
Hi
I think we had this conversation before some weeks ago. From my perspective
I think networking services are normally not considered as first class
citizens of the 'Virtual Datacenter'. What Ishimoto-san describes is a
Virtual Switch. But networking services in the day-in day-out operations
include
On Feb 23, 2011, at 12:26 PM, Vishvananda Ishaya wrote:
We need some sort of supervisor to tell the network to allocate the network
before dispatching a message to compute. I see three possibilities (from
easiest to hardest):
1. Make the call in /nova/compute/api.py (this code runs on
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
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
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.
Also, I am not sure if this is implied by
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
And we are back to the discussion about orchestration... Given the
flexibility of the OpenStack system and the goals of independently
horizontally scaling services I think we will need to address this head on.
#3 is the most difficult, but is also the right answer for the project as we
look
12 matches
Mail list logo
