FLAGS.fixed_range is silly

Bug #741626 reported by Soren Hansen
40
This bug affects 7 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Low
Nathanael Burton

Bug Description

It seems silly to have a statically configured fixed_range *AND* require people to set up networks with nova-manage. AFAICT, it's used exclusively to set up NAT rules. We could just do that on-demand.

Thierry Carrez (ttx)
Changed in nova:
status: New → Confirmed
Revision history for this message
Stanislaw Pitucha (viraptor-gmail) wrote :

There is an additional issue related to fixed_range flag. It's not possible to safely create an environment which doesn't fit completely into one block. If for whatever reason, available range is supposed to include:
10.1.0.0 -- 10.1.3.255
then fixed range will have to be set to 10.1.0.0/22 - including the 10.1.4.0/24 range and setting up a natting rule for it. This might affect existing traffic.

Setting up on-demand iptable rules per project range would be preferred.

Revision history for this message
Nathanael Burton (mathrock) wrote :

I think it would be nice to take care of this bug as it would be fairly simple to fix and offer much more flexibility in allowing for non-contiguous fixed_ranges. In order to be backwards compatible with CONF.fixed_range I was thinking of adding a new config option, say CONF.use_dynamic_fixed_range, which if set to True would figure out the CIDRs to set up for NAT by looking at the networks on the current network host and then setting up the NATs for each. It would default to False such that existing behavior would not change. Does this sound worthwhile? Is this something that would be eligible for FFE for Grizzly or is this too much to be allowed for FFE?

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

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

Changed in nova:
assignee: nobody → mathrock (mathrock)
status: Confirmed → In Progress
tags: added: grizzly-rc-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

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

Changed in nova:
status: In Progress → Fix Committed
Joe Gordon (jogo)
Changed in nova:
milestone: none → grizzly-rc1
tags: removed: grizzly-rc-potential
Thierry Carrez (ttx)
Changed in nova:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in nova:
milestone: grizzly-rc1 → 2013.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.