-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Sorry for reviving an old thread.)
On 01/28/2015 02:55 PM, Ihar Hrachyshka wrote:
On 01/28/2015 09:50 AM, Kevin Benton wrote:
Hi,
Approximately a year and a half ago, the default DHCP lease time
in Neutron was increased from 120 seconds to
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
On Wed, Feb 04, 2015 at 08:59:54, Kevin Benton wrote:
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
On Wed Feb 04 2015 at 8:02:04 PM Kevin Benton blak...@gmail.com wrote:
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)
Miguel Ángel Ajo
On Wednesday, 4 de February de 2015 at 10:41, Cory Benfield wrote:
On Wed, Feb 04, 2015 at 08:59:54, Kevin Benton wrote:
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
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
There's clearly not going to be any amount of time that satisfies both
concerns here.
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:
- Just don't allow users to change their IPs without a
On 02/03/2015 05:10 AM, Kevin Benton wrote:
The unicast DHCP will make it to the wire, but if you've renumbered the
subnet either a) the DHCP server won't respond because it's IP has changed as
well; or b) the DHCP server won't respond because there is no mapping for the
VM
on it's old
On 3 February 2015 at 00:48, Kevin Benton blak...@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
If you had created a second network and subnet this would have been
dropped (different broadcast domain).
Well that update wouldn't have been allowed at the API. You can't use a
fixed IP from a subnet on a network that your port isn't attached to.
Changing a neutron port to a different network
The unicast DHCP will make it to the wire, but if you've renumbered the
subnet either a) the DHCP server won't respond because it's IP has changed
as well; or b) the DHCP server won't respond because there is no mapping
for the VM on it's old subnet.
We aren't changing the DHCP server's IP here.
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
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.
Not as bad as having to delete a port and create another one on the same
network just to change addresses though...
Even with an 8-minute
Kevin,
I think we are finally converging. One of the points I've been trying to make
is that users are playing with fire when they start playing with some of these
port attributes, and given the tool we have to work with (DHCP), the
instantiation of these changes cannot be made seamlessly to a
Kevin,
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.
Even with an 8-minute renew time you're talking up to a 7-minute blackout (87.5%
of lease time before using broadcast). This is time
But they will if we document it well, which is what Salvatore suggested.
I don't think this is a good approach, and it's a big part of why I started
this thread. Most of the deployers/operators I have worked with only read
the bare minimum documentation to get a Neutron deployment working and
On Thu, Jan 29, 2015 at 2:55 AM, Kevin Benton blak...@gmail.com wrote:
Why would users want to change an active port's IP address anyway?
Re-addressing. It's not common, but the entire reason I brought this up is
because a user was moving an instance to another subnet on the same network
and
Why would users want to change an active port's IP address anyway?
Re-addressing. It's not common, but the entire reason I brought this up is
because a user was moving an instance to another subnet on the same network
and stranded one of their VMs.
I worry about setting a default config value
How is Neutron breaking this? If I move a port on my physical switch to a
different subnet, can you still communicate with the host sitting on it?
Probably not since it has a view of the world (next-hop router) that no
longer
exists, and the network won't route packets for it's old IP address to
On 01/29/2015 03:55 AM, Kevin Benton wrote:
Why would users want to change an active port's IP address anyway?
Re-addressing. It's not common, but the entire reason I brought this up is
because a user was moving an instance to another subnet on the same network
and
stranded one of their
On 01/29/2015 05:28 PM, Kevin Benton wrote:
How is Neutron breaking this? If I move a port on my physical switch to a
different subnet, can you still communicate with the host sitting on it?
Probably not since it has a view of the world (next-hop router) that no longer
exists, and the network
On 01/28/2015 09:50 AM, Kevin Benton wrote:
Hi,
Approximately a year and a half ago, the default DHCP lease time in
Neutron was increased from 120 seconds to 86400 seconds.[1] This was
done with the goal of reducing DHCP traffic with very little
discussion (based on what I can see in the
Miguel Ángel Ajo
On Wednesday, 28 de January de 2015 at 09:50, Kevin Benton wrote:
Hi,
Approximately a year and a half ago, the default DHCP lease time in Neutron
was increased from 120 seconds to 86400 seconds.[1] This was done with the
goal of reducing DHCP traffic with very little
On Wed, Jan 28, 2015 at 9:52 AM, Salvatore Orlando sorla...@nicira.com wrote:
The patch Kevin points out increased the lease to 24 hours (which I agree is
as arbitrary as 2 minutes, 8 minutes, or 1 century) because it introduced
use of DHCPRELEASE message in the agent, which is supported by
On Jan 28, 2015, at 9:36 AM, Carl Baldwin c...@ecbaldwin.net wrote:
On Wed, Jan 28, 2015 at 9:52 AM, Salvatore Orlando sorla...@nicira.com
wrote:
The patch Kevin points out increased the lease to 24 hours (which I agree is
as arbitrary as 2 minutes, 8 minutes, or 1 century) because it
If we are going to ignore the IP address changing use-case, can we just
make the default infinity? Then nobody ever has to worry about control
plane outages for existing client. 24 hours is way too long to be useful
anyway.
On Jan 28, 2015 12:44 PM, Salvatore Orlando sorla...@nicira.com wrote:
On 28 January 2015 at 20:19, Brian Haley brian.ha...@hp.com wrote:
Hi Kevin,
On 01/28/2015 03:50 AM, Kevin Benton wrote:
Hi,
Approximately a year and a half ago, the default DHCP lease time in
Neutron was
increased from 120 seconds to 86400 seconds.[1] This was done with the
goal of
On 01/28/2015 12:51 PM, Kevin Benton wrote:
If we are going to ignore the IP address changing use-case, can we
just make the default infinity? Then nobody ever has to worry about
control plane outages for existing client. 24 hours is way too long to
be useful anyway.
Why would users want
The patch Kevin points out increased the lease to 24 hours (which I agree
is as arbitrary as 2 minutes, 8 minutes, or 1 century) because it
introduced use of DHCPRELEASE message in the agent, which is supported by
dnsmasq (to the best of my knowledge) and is functionally similar to
FORCERENEW.
Hi Kevin,
On 01/28/2015 03:50 AM, Kevin Benton wrote:
Hi,
Approximately a year and a half ago, the default DHCP lease time in Neutron
was
increased from 120 seconds to 86400 seconds.[1] This was done with the goal of
reducing DHCP traffic with very little discussion (based on what I can
30 matches
Mail list logo
