Get rid of fixed_range flag

[Soren Hansen]

We should get rid of the fixed_range flag. It's a duplicate of information we also keep in the datastore (after creating the networks with nova-manage). As such, it's something that could be out of sync and lead to much confusion.

AFAICT, it's only ever used with the LinuxNetL3 l3 driver (since it doesn't pass anything to linux_net.init_host()). It's only used to set up iptables rules. It shouldn't be a big deal to make that happen on the fly when networks are added with nova-manage.

[Soren Hansen (soren)]

*chuckle*

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/23787
Committed: http://github.com/openstack/nova/commit/26440ae2cd4c8ffe44beecb6bb0cce19cb43bb7b
Submitter: Jenkins
Branch: master

commit 26440ae2cd4c8ffe44beecb6bb0cce19cb43bb7b
Author: mathrock <email address hidden>
Date: Wed Mar 6 16:28:50 2013 -0500

    Deprecate CONF.fixed_range, do dynamic setup

    Do dynamic fixed_range setup by pulling the networks that should
    exist on the host and making the appropriate calls to set up the NAT
    entries for each network. This allows for non-contiguous subnets to
    be configured in the fixed_ip space and only configures the NAT rules
    as they are needed. This also restricts the NAT range to the smallest
    range required preventing the NAT from impacting subnets that might
    exist on the external network.

    DocImpact: For backwards compatibility, Grizzly will still support
    the CONF.fixed_range option and if set will perform the default logic
    from Folsom and earlier releases. To use the new dynamic fixed_range
    setup in Grizzly, set fixed_range='' in your nova.conf. The intention
    is to remove the CONF.fixed_range option entirely early in the Havana
    cycle and use the dynamic fixed_range setup from Havana going
    forward.

    Change-Id: I4ec111079f7a1d253190e6a6008048f992a53f68
    Fixes: bug #741626 bug #966175