<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 4, 2013 at 10:46 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">On Mon, Mar 4, 2013 at 10:40 AM, Nathanael Burton <span dir="ltr"><<a href="mailto:nathanael.i.burton@gmail.com" target="_blank">nathanael.i.burton@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Vish,<br><br></div>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.</div>

</blockquote><div><br></div></div><div>Can you explain what this functionality would extend that would not be doable via calls to nova-manage network create?<br><br></div></div></div></div></blockquote><div><br></div></div>
Jay,<br><br></div><div class="gmail_extra">Currently the fixed_range CIDR is used to set up the SNAT rules [1] for egress traffic and metadata_host. <br><br></div><div class="gmail_extra">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.<br>
<br></div><div class="gmail_extra">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:<br>
<br>"If for whatever reason, available range is supposed to include:<br>
10.1.0.0 -- 10.1.3.255<br>
then fixed range will have to be set to <a href="http://10.1.0.0/22">10.1.0.0/22</a> - including the 
<a href="http://10.1.4.0/24">10.1.4.0/24</a> range and setting up a natting rule for it. This might 
affect existing traffic."<br><br></div><div class="gmail_extra">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.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">References:<br>[1] <a href="https://github.com/openstack/nova/blob/master/nova/network/linux_net.py#L635">https://github.com/openstack/nova/blob/master/nova/network/linux_net.py#L635</a><br>
[2] <a href="https://bugs.launchpad.net/nova/+bug/741626">https://bugs.launchpad.net/nova/+bug/741626</a><br><br></div><div class="gmail_extra">Thanks,<br><br></div><div class="gmail_extra">Nate<br></div></div>