Project

General

Profile

Actions

Bug #16143

closed

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

Added by Lukas Zapletal over 7 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Urgent
Category:
Discovery plugin
Target version:
Fixed in Releases:
Found in Releases:

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 3 (1 open2 closed)

Related to Discovery - Bug #17613: Discovery, DHCP and lease conflictNew12/08/2016Actions
Related to Discovery - Bug #28330: Reboot/kexec is ussed against new (reserved) IP addressClosedLukas ZapletalActions
Is duplicate of Discovery - Bug #16132: When a Discovered Host is converted to a Managed Host the IP address is not changed to fall within the subnet rangeDuplicateLukas Zapletal08/16/2016Actions
Actions #1

Updated by Lukas Zapletal over 7 years 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.

Actions #2

Updated by Lukas Zapletal over 7 years ago

Test with V2 API as well.

Actions #3

Updated by Lukas Zapletal over 7 years ago

  • Priority changed from Normal to Urgent

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

Actions #4

Updated by Matt Nicholson over 7 years 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.

Actions #5

Updated by Lukas Zapletal over 7 years ago

  • Is duplicate of 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
Actions #6

Updated by Lukas Zapletal over 7 years 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.

Actions #7

Updated by Lukas Zapletal over 7 years ago

  • Target version set to 1.5.2
Actions #8

Updated by Matt Nicholson over 7 years 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.

Actions #9

Updated by Lukas Zapletal over 7 years ago

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

Actions #10

Updated by The Foreman Bot over 7 years ago

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

Updated by Lukas Zapletal over 7 years 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.

Actions #12

Updated by Lukas Zapletal about 7 years ago

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

Updated by Lukas Zapletal over 5 years ago

  • Difficulty changed from easy to medium
  • Triaged set to Yes
Actions #14

Updated by The Foreman Bot over 4 years ago

  • Fixed in Releases Discovery Plugin 16.0 added
Actions #15

Updated by Anonymous over 4 years ago

  • Status changed from Ready For Testing to Closed
Actions #16

Updated by Lukas Zapletal over 4 years ago

  • Related to Bug #28330: Reboot/kexec is ussed against new (reserved) IP address added
Actions #17

Updated by The Foreman Bot about 4 years ago

  • Pull request https://github.com/theforeman/foreman_discovery/pull/496 added
Actions

Also available in: Atom PDF