Bug #16143

Discovered host IP address is not changed to fall within the subnet range

Added by Lukas Zapletal 7 months ago. Updated 16 days ago.

Status:Ready For Testing
Priority:Urgent
Assigned To:Lukas Zapletal
Category:Discovery plugin
Target version:Foreman - Team Daniel - iteration 3
Difficulty:easy Pull request:https://github.com/theforeman/foreman_discovery/pull/306
Bugzilla link:1367549
Story points-
Velocity based estimate-

Description

When booting a host for discovery my understanding is it is using an address from the pool configured in the /etc/dhcp/dhcpd.conf. When converting the host to discovered though the address is not changed to fall within the range specified for the subnet. This can lead to conflicts with later discovered hosts having the same IP address specified as an existing host record does. As reported in https://bugzilla.redhat.com/show_bug.cgi?id=1367549

I believe only auto-provisioning is affected. I tested this without discovery process (bare-metal - new host) and foreman core DOES honor this (I believe this was fixed last year). Therefore we need to correct this in discovery.

# lease of an external host
lease 192.168.223.11 {
  starts 3 2016/08/17 10:20:48;
  ends 0 2016/08/28 23:54:08;
  cltt 3 2016/08/17 10:20:48;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 52:54:00:5a:00:e0;
}
# host was created with the same MAC - reservation from range (110-240)
host test.nested.lan {
  dynamic;
  hardware ethernet 52:54:00:5a:00:e0;
  fixed-address 192.168.223.112;
        supersede server.filename = "pxelinux.0";
        supersede server.next-server = c0:a8:df:01;
        supersede host-name = "test.nested.lan";
}

We need to change traditional and quick provisioning as well in this regard. Changes might be required too.


Related issues

Related to Discovery - Bug #17613: Discovery, DHCP and lease conflict New 12/08/2016
Duplicates Discovery - Bug #16132: When a Discovered Host is converted to a Managed Host the... Duplicate 08/16/2016

History

#1 Updated by Lukas Zapletal 7 months ago

  • Difficulty set to easy

So all we need to do is to call unused_ip for both auto and interactive paths. Smart proxy will take care of the rest. Easy patch.

#2 Updated by Lukas Zapletal 7 months ago

Test with V2 API as well.

#3 Updated by Lukas Zapletal 7 months ago

  • Priority changed from Normal to Urgent

Increasing priority on this one, we are branching 1.13 this week.

#4 Updated by Matt Nicholson 7 months ago

Lukas Zapletal wrote:

Increasing priority on this one, we are branching 1.13 this week.

I'f I'm grok'ing this correctly, this fixes the primary interface portion of http://projects.theforeman.org/issues/16132 which is personally my real blocker for using discovery the way I've hoped to. Happy to help on this however I can as I've got a personal stake in it (and 5K cores of compute I'm hoping to discovery as soon as I can do the unused_ip call!

Actually, one question: would the "unused_ip" call be before/after the hostname template parsing? I ask because in my environment the hostname will be based off the IP, and its critical it be the new IP from unused_ip, not the originally leased IP for discovery. Totally understand if that is a larger/separate issue, worst case for me I get the IP's i want and change my naming pattern to deal w/ it.

#5 Updated by Lukas Zapletal 6 months ago

  • Duplicates Bug #16132: When a Discovered Host is converted to a Managed Host the IP address is not changed to fall within the subnet range added

#6 Updated by Lukas Zapletal 6 months ago

I'f I'm grok'ing this correctly, this fixes the primary interface portion of http://projects.theforeman.org/issues/16132 which is personally my real blocker for using discovery the way I've hoped to. Happy to help on this however I can as I've got a personal stake in it (and 5K cores of compute I'm hoping to discovery as soon as I can do the unused_ip call!

Hello, yup. I am currently working on the patch. I will call unused_ip on all managed interfaces rather than on provisioning interface only.

Actually, one question: would the "unused_ip" call be before/after the hostname template parsing? I ask because in my environment the hostname will be based off the IP, and its critical it be the new IP from unused_ip, not the originally leased IP for discovery. Totally understand if that is a larger/separate issue, worst case for me I get the IP's i want and change my naming pattern to deal w/ it.

Good question, in my WIP branch it's after hostname template rendering, but I think it is worth changing it as you want probably to match hostname with the target IP. I will change that.

To be honest, the reason why it took so long to fix this is I haven't figured this out. On my testing environments and small environments, I always keep the discovered IP and I never run into issues. It's quite surprising this was reported mid-2016.

#7 Updated by Lukas Zapletal 6 months ago

  • Target version set to Team Daniel - iteration 3

#8 Updated by Matt Nicholson 6 months ago

Lukas, if there is anything I can do to help, be it testing or anything, I'm more than happy to. I've got a rollout of a few hundred systems Ive been hoping to use discovery for, but this is my current blocker. I've got a backup plan if it comes down to the wire, but until then I'm happy to do whatever it takes to help get this sorted.

#9 Updated by Lukas Zapletal 6 months ago

Hello, I am currently working on the patch. Can't give you an ETA tho. Will keep you posted.

#10 Updated by The Foreman Bot 6 months ago

  • Status changed from New to Ready For Testing
  • Assigned To set to Lukas Zapletal
  • Pull request https://github.com/theforeman/foreman_discovery/pull/306 added

#11 Updated by Lukas Zapletal 6 months ago

Sorry for the delay, was a bit busy. You can try the initial version:

https://github.com/theforeman/foreman_discovery/pull/306

Note it only implements autoprovisioning for now. The patch is relatively small, there is huge refactoring in the test area.

#12 Updated by Lukas Zapletal 25 days ago

  • Related to Bug #17613: Discovery, DHCP and lease conflict added

Also available in: Atom PDF