Open Stack

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.

Aaron

On Tue, Feb 3, 2015 at 5:25 PM, Kevin Benton <blak111 at gmail.com> wrote:

> 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.
>
> On Tue, Feb 3, 2015 at 5:01 PM, Robert Collins <robertc at robertcollins.net>
> wrote:
>
>> On 3 February 2015 at 00:48, Kevin Benton <blak111 at gmail.com> wrote:
>> >>The only thing this discussion has convinced me of is that allowing
>> users
>> >> to change the fixed IP address on a neutron port leads to a bad
>> >> user-experience.
>> ...
>>
>> >>Documenting a VM reboot is necessary, or even deprecating this (you
>> won't
>> >> like that) are sounding better to me by the minute.
>> >
>> > If this is an approach you really want to go with, then we should at
>> least
>> > be consistent and deprecate the extra dhcp options extension (or at
>> least
>> > the ability to update ports' dhcp options). Updating subnet attributes
>> like
>> > gateway_ip, dns_nameserves, and host_routes should be thrown out as
>> well.
>> > All of these things depend on the DHCP server to deliver updated
>> information
>> > and are hindered by renewal times. Why discriminate against IP updates
>> on a
>> > port? A failure to receive many of those other types of changes could
>> result
>> > in just as severe of a connection disruption.
>>
>> So the reason we added the extra dhcp options extension was to support
>> PXE booting physical machines for Nova baremetal, and then Ironic. It
>> wasn't added for end users to use on the port, but as a generic way of
>> supporting the specific PXE options needed - and that was done that
>> way after discussing w/Neutron devs.
>>
>> We update ports for two reasons. Primarily, Ironic is HA and will move
>> the TFTPd that boots are happening from if an Ironic node has failed.
>> Secondly, because a non uncommon operation on physical machines is to
>> replace broken NICs, and forcing a redeploy seemed unreasonable. The
>> former case doesn't affect running nodes since its only consulted on
>> reboot. The second case is by definition only possible when the NIC in
>> question is offline (whether hotplug hardware or not).
>>
>> -Rob
>>
>>
>> --
>> Robert Collins <rbtcollins at hp.com>
>> Distinguished Technologist
>> HP Converged Cloud
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Kevin Benton
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20150203/07cc68ca/attachment.html>