Open Stack

On Mar 3, 2013 8:21 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:
>
> On Sun, Mar 3, 2013 at 5:27 PM, Nathanael Burton <
nathanael.i.burton at gmail.com> 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?
>
>
> I'm not sure that adding another configuration option to nova.conf is
appropriate here, especially since this kind of thing belongs less in a
configuration file and more as data records in things like Quantum. The
fact that network setup is partly done in nova.conf and partly (mostly!)
done using nova-manage network create is a bad thing and we should not make
the situation worse.
>
> Best,
> -jay
>

Since fixed_range is simply a StrOpt I can just use it and forgo a new
opt.  If it's set to 'dynamic' do the new logic otherwise it's a CIDR and
do the old backwards compatible logic. Aside from the conf option any other
issues with working on this and submitting a patch?

Nate

>>
>> Is this something that would be eligible for Grizzly or is this too much
too late to be allowed in for Grizzly?
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130303/5e553f92/attachment.html>