openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

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 at it is s/scheduler/kernel/
and expand kernel.

Kernel will, as you might guess, tie together various resources. This
includes routing, scheduling, and ensuring things get done just like
a OS kernel manages vm, vfs, hardware devices, process scheduling,
etc. There can be multiple kernel processes/workers (just like there
can be schedulers) for HA. The kernel should define a scheduler API
that schedulers can implement and use (just like today).

My main concern is 'scheduler' is quickly becoming overloaded and
doing things besides scheduling.

Regardless of naming, we should make sure compute nodes never have the
ability to initiate resource requests directly for security reasons,
they should always go through the kernel (which verifies the request
is valid). The API servers should not be coordinating either, this
should be a simple shim over the kernel API (which you can consider
nova/compute.api, nova/network.api, etc. today).

-Eric

On Wed, Feb 23, 2011 at 10:26:55AM -0800, 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/api.py (this code runs on the api host) 
> 2. Make the call in the scheduler (the scheduler then becomes sort of a supervisor to make sure all setup occurs for a vm to launch)
> 3. Create a separate compute supervisor that is responsible for managing the calls to different components
> 
> The easiest seems to be 1, but unfortunately it forces us to wait for the network allocation to finish before returning to the user which i dislike.
> 
> I think ultimately 3 is probably the best solution, but for now I suggest 2 as a middle ground between easy and best.
> 
> Vish
> 
> On Feb 23, 2011, at 5:29 AM, Ishimoto, Ryu 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