Bug #16143: Discovered host IP address is not changed to fall within the subnet range - Discovery - Foreman

Actions

Copy link

Bug #16143

closed

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

Added by Lukas Zapletal over 8 years ago. Updated over 4 years ago.

Status:

Closed

Priority:

Urgent

Assignee:

Lukas Zapletal

Category:

Discovery plugin

Target version:

1.5.2

Difficulty:

medium

Triaged:

Yes

Bugzilla link:

1367549

Pull request:

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

Fixed in Releases:

Discovery Plugin 16.0

Found in Releases:

Red Hat JIRA:

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 open — 2 closed)

Actions

Copy link

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

Copy link

Updated by Lukas Zapletal over 8 years ago

Test with V2 API as well.

Actions

Copy link

Updated by Lukas Zapletal over 8 years ago

Priority changed from Normal to Urgent

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

Actions

Copy link

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

Copy link

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

Copy link

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

Copy link

Updated by Lukas Zapletal over 8 years ago

Target version set to 1.5.2

Actions

Copy link

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

Copy link

Updated by Lukas Zapletal over 8 years ago

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

Actions

Copy link

#10

Updated by The Foreman Bot about 8 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