[2.1] DHCP probe needs to be smarter about interface selection to avoid log spam
Bug #1633717 reported by
Mark Shuttleworth
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| MAAS |
Fix Released
|
Critical
|
Mike Pontillo | ||
Bug Description
I see q steady stream of these in rackd.log:
2016-10-15 13:24:58 [dhcp.detect] DHCP probe failed. No IP address found on interface 'p2p2'.
As I understand it, this is not a *failure* it's just that no IP address was offered up for that interface. In part I suspect this is because the interface is part of a bond, but regardless, the message should probably be changed to reflect that 'no IP address' is not a failure:
2016-10-15 13:24:58 [dhcp.detect] No address for <rackdhost> <interface> on <fabric> VLAN <x>.
Related branches
lp:~mpontillo/maas/dhcp-probe-log-spam--bug-1633717
- Lee Trager (community): Approve
-
Diff: 321 lines (+183/-11)4 files modifiedsrc/provisioningserver/rackdservices/dhcp_probe_service.py (+18/-5)
src/provisioningserver/rackdservices/tests/test_dhcp_probe_service.py (+104/-6)
src/provisioningserver/utils/network.py (+17/-0)
src/provisioningserver/utils/tests/test_network.py (+44/-0)
| description: | updated |
| Changed in maas: | |
| importance: | Undecided → Critical |
| milestone: | none → 2.1.1 |
Revision history for this message
| Mike Pontillo (mpontillo) wrote | #1 |
| Changed in maas: | |
| status: | New → Triaged |
| summary: |
- DHCP probe reports 'failure' when its really just completed + [2.1] DHCP probe needs to be smarter about interface selection to avoid + log spam |
Revision history for this message
| Mark Shuttleworth (sabdfl) wrote Re: [Bug 1633717] Re: DHCP probe reports 'failure' when its really just completed | #2 |
| Changed in maas: | |
| assignee: | nobody → Mike Pontillo (mpontillo) |
| status: | Triaged → In Progress |
| Changed in maas: | |
| status: | In Progress → Fix Committed |
| Changed in maas: | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
Actually, it's more a "failure" than not, but there are some subtleties here. MAAS thought it was a good idea to probe for external DHCP servers on that interface, but wasn't able to send out the [UDP] DHCPv4 packet because no IPv4 address was assigned on that interface. The [legacy] code for DHCPv4 detection didn't try to determine that in advance, and in the past would silently fail here due to a bug in the error surfacing. The lack of error surfacing was fixed as a part of bug #1628645, but uncovered the root cause of this issue: bug #1629106.
I'll leave this bug open so we can address the short-term issue for 2.1.1, which, in my mind, is smarter interface selection before we initiate the external DHCP probe. We should be able to relatively easily avoid interfaces which we can't probe for external DHCP on, which would prevent the annoying log spam.
Left unaddressed, though, will be bug #1629106: that is, MAAS should be able to initiate a DHCP probe on an interface that does not have an IP address assigned to it. (Which I would like to fix, but requires a major design change that is not appropriate for MAAS 2.1.x.) The fact that we require an IP address to initiate a DHCP probe was a surprise to me, and was disappointing to uncover because it defeats the purpose of external DHCP detection in some scenarios.