<div dir="ltr">I proposed an alternative to adjusting the lease time early on the in the thread. By specifying the renewal time (DHCP option 58), we can have the benefits of a long lease time (resiliency to long DHCP server outages) while having a frequent renewal interval to check for IP changes. I favored this approach because it only required a patch to dnsmasq to allow that option to be set and patch to our agent to set that option, both of which are pretty straight-forward.<div><br></div><div>><span style="font-size:12.8000001907349px">- Just don't allow users to change their IPs without a reboot.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">How can we do this? Call Nova from Neutron to force a reboot when the port is updated?</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">></span><span style="font-size:12.8000001907349px">- Bounce the link under the VM when the IP is changed, to force the guest to re-request a DHCP lease immediately.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I had thought about this as well and it's the approach that I think would be ideal, but the Nova VIF code would require changes to add support for changing interface state. It's definition of "plugging" and "unplugging" is actually creating and deleting the interfaces, which might not work so well with running VMs. Then more changes would have to be done on the Nova side to react to a port IP change notification from Neutron to trigger the interface bounce. Finally, a small change would have to be made to Neutron to send the IP change event to Nova.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">The amount of changes it required from the Nova side deterred me from pursuing it further.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">></span><span style="font-size:12.8000001907349px">- Remove the IP spoofing firewall feature</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I think this makes sense as a tenant-configurable option for networks they own, but I don't think we should throw it out. It makes for good protection on networks facing Internet traffic that could have compromised hosts. Along the same line, we make use of shared networks, which has other shady tenants that might be dishonest when it comes to IP addresses.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div>><span style="font-size:12.8000001907349px">- Make the IP spoofing firewall allow an overlap of both old and new addresses until the DHCP lease time is up (or the instance reboots). Adds some additional async tasks, but this is clearly the required solution if we want to keep all our existing features.</span></div><div><br></div><div>I didn't find a clean spot to put this. Spoofing rules are generated a long ways away from the code that knows about IP updates. Maybe we could tack it onto the response to the query from the agent for allowed address pairs. Then we have to deal with persisting these temporary allowed addresses to the DB (not a big deal, but still a schema change). Another issue here would be if Neutron then allocated that address for another port while it was still in use by the old node. We will probably have to block IPAM from re-allocating that address for another port during this window as well.</div><div><br></div><div>However, this doesn't solve the general slowness of DHCP info propagation for other updates (subnet gateway change, DNS nameserver change, etc), so I would still like to go forward with the increased renewal interval. I will also look into eliminating the downtime completely with your last suggestion if it can be implemented without impacting too much stuff.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 3, 2015 at 11:01 PM, Angus Lees <span dir="ltr"><<a href="mailto:gus@inodes.org" target="_blank">gus@inodes.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There's clearly not going to be any amount of time that satisfies both concerns here.<br><br><div>Just to get some other options on the table, here's some things that would allow a non-zero dhcp lease timeout _and_ address Kevin's original bug report:</div><div><br></div><div>- Just don't allow users to change their IPs without a reboot.</div><div><br></div><div>- Bounce the link under the VM when the IP is changed, to force the guest to re-request a DHCP lease immediately.</div><div><br></div><div>- Remove the IP spoofing firewall feature (<- my favourite, for what it's worth. I've never liked presenting a layer2 abstraction but then forcing specific layer3 addressing choices by default)</div><div><br></div><div>- Make the IP spoofing firewall allow an overlap of both old and new addresses until the DHCP lease time is up (or the instance reboots). Adds some additional async tasks, but this is clearly the required solution if we want to keep all our existing features.</div><div><div><br><div class="gmail_quote">On Wed Feb 04 2015 at 4:28:11 PM Aaron Rosen <<a href="mailto:aaronorosen@gmail.com" target="_blank">aaronorosen@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I believe I was the one who changed the default value of this. When we upgraded our internal cloud ~6k networks back then from folsom to grizzly we didn't account that if the dhcp-agents went offline that instances would give up their lease and unconfigure themselves causing an outage. Setting a larger value for this helps to avoid this downtime (as Brian pointed out as well). Personally, I wouldn't really expect my instance to automatically change it's ip - I think requiring the user to reboot the instance or use the console to correct the ip should be good enough. Especially since this will help buy you shorter down time if an agent fails for a little while which is probably more important than having the instance change it's ip.</div><div dir="ltr"><div><br></div><div>Aaron</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 3, 2015 at 5:25 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I definitely understand the use-case of having updatable stuff and I don't intend to support any proposals to strip away that functionality. Brian was suggesting was to block port IP changes since it depended on DHCP to deliver that information to the hosts. I was just pointing out that we would need to block any API operations that resulted in different information being delivered via DHCP for that approach to make sense.</div><div class="gmail_extra"><div><div><br><div class="gmail_quote">On Tue, Feb 3, 2015 at 5:01 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 3 February 2015 at 00:48, Kevin Benton <<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>> wrote:<br>
>>The only thing this discussion has convinced me of is that allowing users<br>
>> to change the fixed IP address on a neutron port leads to a bad<br>
>> user-experience.<br>
</span>...<br>
<span><br>
>>Documenting a VM reboot is necessary, or even deprecating this (you won't<br>
>> like that) are sounding better to me by the minute.<br>
><br>
> If this is an approach you really want to go with, then we should at least<br>
> be consistent and deprecate the extra dhcp options extension (or at least<br>
> the ability to update ports' dhcp options). Updating subnet attributes like<br>
> gateway_ip, dns_nameserves, and host_routes should be thrown out as well.<br>
> All of these things depend on the DHCP server to deliver updated information<br>
> and are hindered by renewal times. Why discriminate against IP updates on a<br>
> port? A failure to receive many of those other types of changes could result<br>
> in just as severe of a connection disruption.<br>
<br>
</span>So the reason we added the extra dhcp options extension was to support<br>
PXE booting physical machines for Nova baremetal, and then Ironic. It<br>
wasn't added for end users to use on the port, but as a generic way of<br>
supporting the specific PXE options needed - and that was done that<br>
way after discussing w/Neutron devs.<br>
<br>
We update ports for two reasons. Primarily, Ironic is HA and will move<br>
the TFTPd that boots are happening from if an Ironic node has failed.<br>
Secondly, because a non uncommon operation on physical machines is to<br>
replace broken NICs, and forcing a redeploy seemed unreasonable. The<br>
former case doesn't affect running nodes since its only consulted on<br>
reboot. The second case is by definition only possible when the NIC in<br>
question is offline (whether hotplug hardware or not).<br>
<br>
-Rob<br>
<span><font color="#888888"><br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com" target="_blank">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
</font></span><div><div><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div><div>Kevin Benton</div></div>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div>Kevin Benton</div></div>
</div></div>