FlatManagerIPv6Support

Summary

IPV6 is already supported for FlatDHCP and VLAN network model in Bexar release. Add support to Flat network model also

TBD

Currently nova support FlatManager with single bridge that you specify in flat_network_bridge (br100 by default). This bridge needs to be created on all compute hosts by the user.
Creating multiple networks is currently not supported
If flat_injected is True, the compute host will attempt to inject network config into the guest. It attempts to modify /etc/network/interfaces and currently only works on debian based systems. To support a wider range of OSes, some other method may need to be devised to let the guest know which ip it should be using so that it can configure itself.

Add database column netmask_v6 in the networks database table.
Modify ra_server database column of networks tables to gateway_v6.
- Reason : When we implemented IPv6 support for FlatDHCP and Vlan network model, we added new ra_server column in the networks database table. However we think for Flat network model, this name ra_server column is not suitable. Because for all 3 network models, routers acts as a gateway which forwards the packets from inside and outside of the cloud and for only VlanManager or FlatDHCPManager, routers advertises RA messages. Then in generally, those routers should be called as not "RA server" but just "gateway".
Populate netmask_v6 when you create networks using nova-manage network create commmand.
update gateway_v6 column when network host is selected for a project. Get the ipv6 local link address of the bridge you have created on the network node manually and update this local link address in the gateway_v6 column of the network.
Modify the interfaces.template to include following
- ###Start IPV6 static configuration
  - iface eth0 inet6 static
  - address %(address_v6)s
  - netmask %(netmask_v6)s
  - gateway %(gateway_v6)s
- ###END IPV6
- If use_ipv6 flag is set to True, then only the above IPV6 configuration will be injected in the /etc/network/interfaces of the VM instance.
Modify libvirt_conn.py for filtering security groups

There should be no visible changes to the end users, all this work will be behind the network/compute servers.

Database migration is required for the newly added and modified columns to the networks and fixed_ips database tables.

Unit tests will be added as the code is developed. System testing will be on Ubuntu Lucid.

None