The plan is to leave the auth manager code in but mention that it is deprecated. There is a sample paste config in ini to still allow old auth. Immediately after the diablo release we can tear out all of the Auth related code and not support the deprecated auth anymore.
1) Specify number and order of networks to the create server API.
In the current implementation every instance you launch for a project having 3 networks assigned to it will always have 3 vnics. In this case it is not possible to have one instance with 2 vnics ,another with 1 vnic and so on. This is not flexible enough and the network resources are not used effectively.
2) Specify fixed IP address to the vnic at the boot time. When you launch a server, you can specify the fixed IP address you want to be assigned to the vnic from a particular network. If this fixed IP address is already in use, it will give exception.
Example of Server Create API request XML:
<?xml version="1.0" encoding="UTF-8"?>
<server xmlns="http://docs.nttpflab.com/servers/api/v1.0"
name="new-server-test" imageId="1" flavorId="1">
<metadata>
<meta key="My Server Name">Apache1</meta>
</metadata>
<personality>
<file path="/etc/banner.txt">
ICAgICAgDQoiQSBjbG91ZCBkb2VzIG5vdCBrbm93IHdoeSBp
</file>
</personality>
<networks>
<network uuid="6622436e-5289-460f-8479-e4dcc63f16c5" fixed_ip="10.0.0.3">
<network uuid="d97efefc-e071-4174-b6dd-b33af0a37706" fixed_ip="10.0.1.3">
</networks>
</server>
3) Networks is an optional parameter, so if you don't provide any networks to the server Create API, it will behave exactly the same as of today.
This feature is supported to all of the network models.
In Diablo-3 we introduced "vif-plugging" to the hypervisor "virt" layer, allowing flexibility in how vNICs are attached to the network switch. This allowed non-linux bridge switch technologies (e.g., Open vSwitch, 802.1qbh) to be used with nova.
This blueprint adds a similar capability to linux_net.py, allowing the L3/DHCP capabilities to be "plugged" into Quantum networks. Like in the virt layer, we created a vif driver that represents the behavior of Nova prior to the change (LinuxBridgeInterfaceDriver) and make it the default. We also add a new driver for Open Vswitch that can be enabled using a flag (LinuxOVSInterfaceDriver). The code is designed to support other drivers as well.
Most of the interesting code is at the bottom of linux_net.py, where the drivers are defined. I had to pull some common code related to setting IPs on devices out of ensure_bridge() so it could be used by either approach. The driver's plug() method is invoked by the VlanManager's _setup_network() method. Currently unplug() is unused, which seems to be inline with how the existing nova code works.
In many places in linux_net.py, I had to tweak functions to accept the name of the linux device to configure, rather than just assuming it was the 'bridge' field in the network object, since with OVS it could be any linux device. The code I am least sure about are the changes to bin/nova-dhcpbridge. I changed to this key off of the network ID, rather than the bridge name.
I've tested this with the linux bridge and with the OVS vif-plugging driver. I was able to confirm that L3 forwarding and DHCP were operating correctly.
Now changes have been made in the create_instance_helper to read the availability zone and pass it to the compute create API. Any OS extensions can take a advantage of it.
Also changes have been made in the nova-manage ServiceCommands class to expose zone information to the admin users. Only admin users will be allowed to launch VM instance on specific host.
vladimir.p