Open Stack

On Mon, Mar 4, 2013 at 10:46 AM, Jay Pipes <jaypipes at gmail.com> wrote:

> On Mon, Mar 4, 2013 at 10:40 AM, Nathanael Burton <
> nathanael.i.burton at gmail.com> wrote:
>
>> Vish,
>>
>> Do you think this would be eligible for FFE for Grizzly?  Does it seem
>> worthwhile?  As I've said above, I can reuse the 'fixed_range' above for
>> Grizzly and override it to use some string like 'dynamic'. Additionally, we
>> could mark the flag as deprecated in Grizzly, and then remove it in
>> Hipster(err...Havana) and use the dynamic fixed_range from that point
>> forward.
>>
>
> Can you explain what this functionality would extend that would not be
> doable via calls to nova-manage network create?
>
>
Jay,

Currently the fixed_range CIDR is used to set up the SNAT rules [1] for
egress traffic and metadata_host.

Problem 1: Users have to specify the 'fixed_range' in the first place in
their nova.conf file, when it shouldn't be necessary as the system (DB
networks table) has all the information it needs to set up the NATs
correctly.  If this eventually gets implemented we can deprecate and then
remove the flag entirely in Havana or future.

Problem 2: Since 'fixed_range' is a single CIDR, you have to make it
sufficiently large enough to encompass all the networks you've defined with
nova-manage network create. This leads to cases where you have to make it
larger than the subnets you are actually using, especially if for whatever
reason your network range is not contiguous.  An example of this is in the
bug [2] but posted here for reference:

"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."

Proposal: The fix proposed in patches I've tested locally (need to clean
up, write test cases, and add to devstack(?)), pulls the configured
networks on a host via the network api and then calls the init_host() code
for each network.  Aside from configuring things automatically, this has
the side benefit of configuring only what networks are needed and currently
in use on the host.

References:
[1]
https://github.com/openstack/nova/blob/master/nova/network/linux_net.py#L635
[2] https://bugs.launchpad.net/nova/+bug/741626

Thanks,

Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130304/8f3b3ae9/attachment.html>