openstack team mailing list archive

["Ishimoto, Ryu" <ryu@xxxxxxxxxxx>]

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