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 long
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
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
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 new service
> called "ke
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
definitely not fine to use dhcp in all cases.
On Thu, Feb 24, 2011 at 3:28 AM, Dan Mihai Dumitriu 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
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 new service
called "kernel". Another way to look
On 2/23/11 12:26 PM, Vishvananda Ishaya wrote:
Agreed that this is the right way to go.
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/
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 o
lists.launchpad.net
> Subject: Re: [Openstack] Decoupling of Network and Compute services for the
> new Network Service design
>
> Agreed that this is the right way to go.
>
> We need some sort of supervisor to tell the network to allocate the network
> before dispatching a mess
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 wrote:
>
> Hi everyone,
> I have
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
Hi Vish,
> 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 the api host)
> 2. Make the call in the schedu
John Purrier wrote:
> 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 th
+john=openstack@lists.launchpad.net] On Behalf
Of Vishvananda Ishaya
Sent: Wednesday, February 23, 2011 12:27 PM
To: Ishimoto, Ryu
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Decoupling of Network and Compute services for the
new Network Service design
Agreed that this is the
Agreed that this is the right way to go.
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 the api host)
2. Make
unces+john=openstack@lists.launchpad.net] On Behalf
Of Dan Wendlandt
Sent: Wednesday, February 23, 2011 7:49 AM
To: Ishimoto, Ryu
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Decoupling of Network and Compute services for the
new Network Service design
I think this is very much i
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 step
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
19 matches
Mail list logo
