Cannot launch an instance with IPv6 subnet

After I looked around nova flags for a while, I noticed I must set use_ipv6=True.
By setting use_ivp6 to True, the issue I reported is addressed. Thus I will change the status to 'invalid'.

One thing I want to know is why use_ipv6 is set False by default. Are there any reasons for it?

I rechecked and confirmed this bug happens even if use_ipv6 is True, so I reset the status to "New" from "Invalid".

Unlike the original bug description, IPv6 address is assigned to an instance but launching an instance failed.

command lines and nova-compute log => http://paste.openstack.org/show/20634/
nova.conf => http://paste.openstack.org/show/20633/

git|glance|master[1d91a4d]
git|horizon|master[6e949ac]
git|keystone|master[2759c22]
git|nova|master[0318efe]
git|noVNC|master[cbb55df]
git|python-glanceclient|master[e233f66]
git|python-keystoneclient|master[0a8c960]
git|python-novaclient|master[3a89425]
git|python-openstackclient|master[8010e77]
git|python-quantumclient|master[62f5089]
git|quantum|master[d8160e0]

Is this is covered by the following blueprint: https://blueprints.launchpad.net/quantum/+spec/ipv6-feature-parity ?

I was able to reproduce this bug in the following manner:

0. in nova.conf: "network_manager = nova.network.manager.FlatManager"
1. `nova network-create --fixed-range-v6 2001:db8:dead:beef::/64 ipv6net`
2. `nova boot --image $IMAGE --flavor $FLAVOR --nic net-id=$NET-ID new-server`
3. a. `nova list`. Observe new-server in ERROR state.
   b. `nova show`. fault is "{u'message': u'NoValidHost', u'code': 500, u'created': u'2013-01-30T17:38:57Z'}"
   c. Observe error "NovaException: v4 subnets are required for legacy nw_info" in nova-compute logs.

I will begin working on a fix.

From running `grep -nH -R -e "legacy()" .` on the code base I have come up with an approach. Let me know if I have missed anything. My current plan of attack is as follows:

0. Make each of the compute drivers compatible with the current network model (non-legacy), pushing any legacy dependency into the firewall driver.
From my enumeration that means: i. baremetal.BareMetalDriver <bug 1112642> ii. libvirt.LibvirtDriver <bug 1112646>, and iii. vmwareapi.VMwareESXDriver <bug 1112655>.

1. Remove legacy_nwinfo from the nova.virt.driver.ComputeDriver base class. This involves minor code changes (test code and stub drivers) once the previous step is completed.

2. Fix the firewall driver to use the current network model. <bug 1112657>

3. Fix any other legacy-dependent code to use the current network model (e.g. nova.virt.netutils.get_injected_network_template) <bug 1112659>

4. Remove the legacy function from the network model.

Fix proposed to branch: master
Review: https://review.openstack.org/22360

Fix proposed to branch: master
Review: https://review.openstack.org/22373

I had the same trouble today. Wonder what's going on with the review, and also which patch (22360 or 22373) is actually fixing the issue. thanks.

I've resumed working on the patch for havana, but progress has slowed as I haven't been able to allocate much time to it.