[library] neutron-dhcp-agent got configured wrong each time when got started

[Aleksandr Shaposhnikov]

By some reason when neutron-dhcp-agent is under corosync management it got configured somehow wrong because after each and every move between nodes it got assigned new IP/Port when old one still kept in database and occupying IP. It basically wrong because of two reasons: IP addresses wouldn't be renewed (only requested again through discovery) and IP addresses for old instances got wasted and wouldn't be used anymore until deleting them from DB.

Steps to reproduce:

1. Deploy ubuntu ha configuration.
2. Write down IP address fro DHCP server in default network net04.
3. Using crm force move of dhcp agent on the different controller.
4. Take a look on new IP address that dhcp server got allocated for himself.

Observed behavior:

dhcp-server got new ip address from net04 network. Old one port went down and not used anymore but still in db and couldn't be used for instances. Instances wouldn't be able to renew address. When ip address lease will be end they will send new discovery and request instead of just direct lease prolong request by using old IP.

[Mike Scherbakov (mihgen)]

mihgen: aleksandr_null: good what Fuel version is it?
[11:58am] aleksandr_null: 5.0
[11:58am] aleksandr_null: and all previous

[Vladimir Kuklin (vkuklin)]

Alex, this bug looks invalid for following reason:

1) different dhcp addresses for different dhcp agents is normal. you can run several dhcp agents in the same network
2) data is fetched from db along with leases information, so it should not affect VM instances

If you have any evidence, that I am wrong, please provide more diagnostic information how to reproduce it, because my experience with neutron shows that you are wrong. Also, it may be related to openstack code itself, not to the way how we deploy it.

[Aleksandr Shaposhnikov (alashai8)]

DHCP RFC:

3.7 When clients should use DHCP

   A client SHOULD use DHCP to reacquire or verify its IP address and
   network parameters whenever the local network parameters may have
   changed; e.g., at system boot time or after a disconnection from the
   local network, as the local network configuration may change without
   the client's or user's knowledge.

   If a client has knowledge of a previous network address and is unable
   to contact a local DHCP server, the client may continue to use the
   previous network address until the lease for that address expires.
   If the lease expires before the client can contact a DHCP server, the
   client must immediately discontinue use of the previous network
   address and may inform local users of the problem.

P.S. Some OSes could really stop using old address until new DHCP address is received. It's just following proto RFC. So we should take care also.

[Aleksandr Shaposhnikov (alashai8)]

Also DHCP RFC 4.4.5:

If the lease expires before the client receives a DHCPACK, the client
   moves to INIT state, MUST immediately stop any other network
   processing and requests network initialization parameters as if the
   client were uninitialized. If the client then receives a DHCPACK
   allocating that client its previous network address, the client
   SHOULD continue network processing. If the client is given a new
   network address, it MUST NOT continue using the previous network
   address and SHOULD notify the local users of the problem.

[Dmitry Borodaenko (angdraug)]

The problem can only be addressed in Neutron. Aleksandr, please post a link to an upstream bug in the comments if it already exists.

[Ilya Shakhat (shakhat)]

I don't see any issue in the current behavior. RFC 2131 allows to have several DHCP servers in the network and all of them can participate IP offering. (see §3.1 "Client-server interaction - allocating a network address"). It would be a valid case even if one network is scheduled to many dhcp agents.

The only drawback of dhcp agent migration is consumption of IP addresses and ports. By design the port is linked to agent host. The port is reused if agent migrates to the same host for another time. So there cannot be more than {{controller}} number of IPs occupied by dhcp agent.

Moving the issue into 'Won't Fix' since the behavior is as-designed.