FLAGS.fixed_range is silly
Bug #741626 reported by
Soren Hansen
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.
Changed in nova: | |
status: | New → Confirmed |
tags: | added: grizzly-rc-potential |
Changed in nova: | |
milestone: | none → grizzly-rc1 |
tags: | removed: grizzly-rc-potential |
Changed in nova: | |
status: | Fix Committed → Fix Released |
Changed in nova: | |
milestone: | grizzly-rc1 → 2013.1 |
To post a comment you must log in.
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.