Discovery, DHCP and lease conflict

Support
1

Hello,

I am testing the Discovery plugin. I have a DHCP server setup to assign a
limited range of addresses (dedicated to pxe booting hosts). The remaining
addresses are out of the DHCP scope to be permanently assigned to the
hosts. Foreman is configured to autosuggest IPs outside of the DHCP range.
I'm having this problem:

  1. boot new host, it gets discovered
  2. open the "provision" > "interfaces" tab. The IP pre-assigned is the
    one that has been provided by DHCP during PXE boot
  3. Manually change the address to an address of choice from outside the
    DHCP range. This will be the real host IP
  4. Foreman throws a "DHCP records <mac>/<IP> already exists" warning and
    asks me if I want to overwrite it

Is this the expected behavior? The lease is indeed there because of the PXE
boot, so the conflict warning makes sense.
I would like foreman to let me choose whatever IP I want for the host,
instead.
The conflict error appears even when configuring the IPAM dropdown in the
subnet config to "none".

I read a few threads dealing with the same situation but it's still not
clear to me what would be the suggested DHCP deployment scenario.

Thank you!

2

Hmmm we have a bit of code around leases - the IP address that was assigned
via lease, we should ignore it.

Are you also changing the hostname? Can you try without changing the
hostname?

Also increasing Rails app logging level to debug should show this:

  logger.debug &quot;Comparing #{attrs.values_at(*to_compare)} ==

#{other.attrs.values_at(*to_compare)}"

So we can see all the validations from there.

··· On Thu, Dec 8, 2016 at 3:33 PM, Alexander Rilik wrote:

Hello,

I am testing the Discovery plugin. I have a DHCP server setup to assign a
limited range of addresses (dedicated to pxe booting hosts). The remaining
addresses are out of the DHCP scope to be permanently assigned to the
hosts. Foreman is configured to autosuggest IPs outside of the DHCP range.
I’m having this problem:

  1. boot new host, it gets discovered
  2. open the “provision” > “interfaces” tab. The IP pre-assigned is the
    one that has been provided by DHCP during PXE boot
  3. Manually change the address to an address of choice from outside
    the DHCP range. This will be the real host IP
  4. Foreman throws a “DHCP records / already exists” warning
    and asks me if I want to overwrite it

Is this the expected behavior? The lease is indeed there because of the
PXE boot, so the conflict warning makes sense.
I would like foreman to let me choose whatever IP I want for the host,
instead.
The conflict error appears even when configuring the IPAM dropdown in the
subnet config to “none”.

I read a few threads dealing with the same situation but it’s still not
clear to me what would be the suggested DHCP deployment scenario.

Thank you!

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
Later,
Lukas @lzap Zapletal

3

I was actually having similar issues with it this week, another issue is
using the "hammer" cli to provision the host with a specific interface
configuration (i suspect it's related as we have a similar configuration)
$ hammer discovery provision
–id=80
–build=1
–enabled=1
–managed=1
–hostgroup-id=9
–new-name=server1
–owner-id=4
–provision-method=build
–interface="type=bond,mac=0c:c4:74:b3:9c:ba,identifier=bond0,name=server1,domain_id=1,subnet_id=11,ip=172.14.20.13,managed=true,primary=true,provision=true,mode=802.3ad,attached_devices=[enp1s0f0,enp1s0f1]"

–interface="type=interface,mac=0c:c4:74:b3:9c:ba,identifier=enp1s0f0,domain_id=1,subnet_id=11,managed=true"

–interface="type=interface,mac=0c:c4:74:b3:9c:bb,identifier=enp1s0f1,managed=true"

  1. It doesn't inherit puppet, puppet ca and realm proxy configuration from
    the hostgroup while it does inherit the operating system related
    configuration.
  2. it doesn't create/modify anything under the network configuration, it
    leaves the IP that was handed off by the DHCP, and same with the writer of
    this post, it's a different range used for provisioning only.

An identical "hammer" command works fine when creating a new host.
$ hammer host create
–build=1
–enabled=1
–managed=1
–hostgroup-id=9
–name="server1"
–owner-id=4
–provision-method=build
–interface="type=bond,mac=0c:c4:74:b3:9c:ba,identifier=bond0,name=server1,domain_id=1,subnet_id=11,ip=172.14.20.13,managed=true,primary=true,provision=true,mode=802.3ad,attached_devices=[enp1s0f0,enp1s0f1]"

–interface="type=interface,mac=0c:c4:74:b3:9c:ba,identifier=enp1s0f0,domain_id=1,subnet_id=11,managed=true"

–interface="type=interface,mac=0c:c4:74:b3:9c:bb,identifier=enp1s0f1,managed=true"

··· On Thursday, December 8, 2016 at 4:33:26 PM UTC+2, Alexander Rilik wrote: > > Hello, > > I am testing the Discovery plugin. I have a DHCP server setup to assign a > limited range of addresses (dedicated to pxe booting hosts). The remaining > addresses are out of the DHCP scope to be permanently assigned to the > hosts. Foreman is configured to autosuggest IPs outside of the DHCP range. > I'm having this problem: > > 1. boot new host, it gets discovered > 2. open the "provision" > "interfaces" tab. The IP pre-assigned is the > one that has been provided by DHCP during PXE boot > 3. Manually change the address to an address of choice from outside > the DHCP range. This will be the real host IP > 4. Foreman throws a "DHCP records / already exists" warning > and asks me if I want to overwrite it > > Is this the expected behavior? The lease is indeed there because of the > PXE boot, so the conflict warning makes sense. > I would like foreman to let me choose whatever IP I want for the host, > instead. > The conflict error appears even when configuring the IPAM dropdown in the > subnet config to "none". > > I read a few threads dealing with the same situation but it's still not > clear to me what would be the suggested DHCP deployment scenario. > > Thank you! > > >
4

Hello Lukas,

I tried without changing the hostname, same thing. This is what I get on
the foreman master with debug enabled:

2016-12-08T15:11:18 6c52e832 [app] [I] Parameters: {"utf8"=>"✓",
"authenticity_token"=>"5X6uGLWNqGzNLXJRkoz5I9HGRMvZ504n37l0XdxiBdQnaCOKdKdpsn0KoOIxK/wKuaAM5NL/2CL+0mWg56AWEw==",
"host"=>{"name"=>"mac080027977078", "hostgroup_id"=>"7",
"ansible_role_ids"=>[""], "managed"=>"true",
"progress_report_id"=>"[FILTERED]", "type"=>"Host::Managed",
"interfaces_attributes"=>{"0"=>{"_destroy"=>"0",
"mac"=>"08:00:27:97:70:78", "identifier"=>"enp0s3",
"name"=>"mac080027977078", "domain_id"=>"1", "subnet_id"=>"8",
"ip"=>"192.168.60.39", "ip6"=>"", "managed"=>"1", "primary"=>"1",
"provision"=>"1", "tag"=>"", "attached_to"=>"", "id"=>"154"}},
"architecture_id"=>"1", "operatingsystem_id"=>"1", "build"=>"1",
"medium_id"=>"7", "ptable_id"=>"82", "pxe_loader"=>"PXELinux BIOS",
"disk"=>"", "is_owned_by"=>"3-Users", "enabled"=>"1", "model_id"=>"1",
"comment"=>"", "overwrite"=>"false"},
"discovered_host"=>{"puppetclass_ids"=>[""]},
"bare_metal_capabilities"=>"build", "id"=>"mac080027977078"}
2016-12-08T15:11:18 6c52e832 [app] [D] Setting current user thread-local
variable to admin
2016-12-08T15:11:18 6c52e832 [app] [D] Setting current organization
thread-local variable to none
2016-12-08T15:11:18 6c52e832 [app] [D] Setting current location
thread-local variable to none
2016-12-08T15:11:18 6c52e832 [app] [D] Comparing ["08:00:27:97:70:78",
"192.168.60.112", "192.168.60.0"] == ["08:00:27:97:70:78", "192.168.60.39",
"192.168.60.0"]
2016-12-08T15:11:19 6c52e832 [app] [D] Comparing ["08:00:27:97:70:78",
"192.168.60.112", "192.168.60.0"] == ["08:00:27:97:70:78", "192.168.60.39",
"192.168.60.0"]
2016-12-08T15:11:19 6c52e832 [app] [I] Failed to save: Conflict DHCP
records -08:00:27:97:70:78/192.168.60.112 already exists, Conflict DHCP
records -08:00:27:97:70:78/192.168.60.112 already exists
2016-12-08T15:11:19 6c52e832 [app] [I] Rendered hosts/_conflicts.html.erb
(0.7ms)
2016-12-08T15:11:19 6c52e832 [app] [I] Rendered hosts/_progress.html.erb
(0.7ms)
2016-12-08T15:11:19 6c52e832 [app] [D] Setting current organization
thread-local variable to none
2016-12-08T15:11:19 6c52e832 [app] [D] Setting current location
thread-local variable to none
2016-12-08T15:11:19 6c52e832 [app] [I] Rendered nic/_base_form.html.erb
(22.8ms)

The dhcp server is configured as following:

subnet 192.168.60.0 netmask 255.255.255.0 {
pool
{
range 192.168.60.110 192.168.60.150;
}

option subnet-mask 255.255.255.0;
option routers 192.168.60.4;
}

The subnet is currently configured with IPAM = none

··· On Thursday, December 8, 2016 at 3:46:08 PM UTC+1, Lukas Zapletal wrote: > > Hmmm we have a bit of code around leases - the IP address that was > assigned via lease, we should ignore it. > > Are you also changing the hostname? Can you try without changing the > hostname? > > Also increasing Rails app logging level to debug should show this: > > logger.debug "Comparing #{attrs.values_at(*to_compare)} == > #{other.attrs.values_at(*to_compare)}" > > So we can see all the validations from there. > > -- > Later, > Lukas @lzap Zapletal >

Thanks!

5

Thanks, since you have reproducer handy, can you try again with normal host
(not discovered host)?

Please file a ticket with this info, thanks.

LZ

··· On Thu, Dec 8, 2016 at 4:16 PM, Alexander Rilik wrote:

On Thursday, December 8, 2016 at 3:46:08 PM UTC+1, Lukas Zapletal wrote:

Hmmm we have a bit of code around leases - the IP address that was
assigned via lease, we should ignore it.

Are you also changing the hostname? Can you try without changing the
hostname?

Also increasing Rails app logging level to debug should show this:

  logger.debug "Comparing #{attrs.values_at(*to_compare)} ==

#{other.attrs.values_at(*to_compare)}"

So we can see all the validations from there.

Hello Lukas,

I tried without changing the hostname, same thing. This is what I get on
the foreman master with debug enabled:

2016-12-08T15:11:18 6c52e832 [app] [I] Parameters: {“utf8”=>“✓”,
“authenticity_token”=>“5X6uGLWNqGzNLXJRkoz5I9HGRMvZ50
4n37l0XdxiBdQnaCOKdKdpsn0KoOIxK/wKuaAM5NL/2CL+0mWg56AWEw==”,
“host”=>{“name”=>“mac080027977078”, “hostgroup_id”=>“7”,
“ansible_role_ids”=>[""], “managed”=>“true”, “progress_report_id”=>"[FILTERED]",
“type”=>“Host::Managed”, “interfaces_attributes”=>{“0”=>{"_destroy"=>“0”,
“mac”=>“08:00:27:97:70:78”, “identifier”=>“enp0s3”,
“name”=>“mac080027977078”, “domain_id”=>“1”, “subnet_id”=>“8”,
“ip”=>“192.168.60.39”, “ip6”=>"", “managed”=>“1”, “primary”=>“1”,
“provision”=>“1”, “tag”=>"", “attached_to”=>"", “id”=>“154”}},
“architecture_id”=>“1”, “operatingsystem_id”=>“1”, “build”=>“1”,
“medium_id”=>“7”, “ptable_id”=>“82”, “pxe_loader”=>“PXELinux BIOS”,
“disk”=>"", “is_owned_by”=>“3-Users”, “enabled”=>“1”, “model_id”=>“1”,
“comment”=>"", “overwrite”=>“false”}, “discovered_host”=>{“puppetclass_ids”=>[""]},
“bare_metal_capabilities”=>“build”, “id”=>“mac080027977078”}
2016-12-08T15:11:18 6c52e832 [app] [D] Setting current user thread-local
variable to admin
2016-12-08T15:11:18 6c52e832 [app] [D] Setting current organization
thread-local variable to none
2016-12-08T15:11:18 6c52e832 [app] [D] Setting current location
thread-local variable to none
2016-12-08T15:11:18 6c52e832 [app] [D] Comparing [“08:00:27:97:70:78”,
“192.168.60.112”, “192.168.60.0”] == [“08:00:27:97:70:78”, “192.168.60.39”,
“192.168.60.0”]
2016-12-08T15:11:19 6c52e832 [app] [D] Comparing [“08:00:27:97:70:78”,
“192.168.60.112”, “192.168.60.0”] == [“08:00:27:97:70:78”, “192.168.60.39”,
“192.168.60.0”]
2016-12-08T15:11:19 6c52e832 [app] [I] Failed to save: Conflict DHCP
records -08:00:27:97:70:78/192.168.60.112 already exists, Conflict DHCP
records -08:00:27:97:70:78/192.168.60.112 already exists
2016-12-08T15:11:19 6c52e832 [app] [I] Rendered
hosts/_conflicts.html.erb (0.7ms)
2016-12-08T15:11:19 6c52e832 [app] [I] Rendered hosts/_progress.html.erb
(0.7ms)
2016-12-08T15:11:19 6c52e832 [app] [D] Setting current organization
thread-local variable to none
2016-12-08T15:11:19 6c52e832 [app] [D] Setting current location
thread-local variable to none
2016-12-08T15:11:19 6c52e832 [app] [I] Rendered nic/_base_form.html.erb
(22.8ms)

The dhcp server is configured as following:

subnet 192.168.60.0 netmask 255.255.255.0 {
pool
{
range 192.168.60.110 192.168.60.150;
}

option subnet-mask 255.255.255.0;
option routers 192.168.60.4;
}

The subnet is currently configured with IPAM = none

–

Later,
Lukas @lzap Zapletal

Thanks!

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
Later,
Lukas @lzap Zapletal

6

I hit this as well, but I thought it was related to the webgui! Are you
referring to this? Bug #9784: Autoprovisioning via hostgroup does not populate all parameters via WebUI or API - Discovery - Foreman

··· On Friday, December 9, 2016 at 5:22:24 PM UTC+1, Erez Zarum wrote: > > > 1) It doesn't inherit puppet, puppet ca and realm proxy configuration from > the hostgroup while it does inherit the operating system related > configuration. >
7

Looks good in normal host mode, no issues! I tried both the IPAM DHCP and
the IPAM None.
I created the ticket Bug #17613: Discovery, DHCP and lease conflict - Discovery - Foreman.

Thanks for the help!
Nicola

··· On Thursday, December 8, 2016 at 4:32:22 PM UTC+1, Lukas Zapletal wrote: > > Thanks, since you have reproducer handy, can you try again with normal > host (not discovered host)? > > Please file a ticket with this info, thanks. > > LZ >
8

Yes, up to now, i have not suffered from that much because so far i could
set those settings manually and they were applied, but i assume in a large
complex environment it could create some issues.

··· On Friday, December 9, 2016 at 7:12:16 PM UTC+2, Alexander Rilik wrote: > > On Friday, December 9, 2016 at 5:22:24 PM UTC+1, Erez Zarum wrote: >> >> >> 1) It doesn't inherit puppet, puppet ca and realm proxy configuration >> from the hostgroup while it does inherit the operating system related >> configuration. >> > > I hit this as well, but I thought it was related to the webgui! Are you > referring to this? http://projects.theforeman.org/issues/9784#note-38 >
9

Oh I was not aware that API provisioning is also affected by the
non-inherited Puppet flags.

The other one (unused_ip API is never called) is tracked under:
http://projects.theforeman.org/issues/16143

We are actively working on both bugs.

LZ

··· On Fri, Dec 9, 2016 at 8:31 PM, Erez Zarum wrote:

Yes, up to now, i have not suffered from that much because so far i could
set those settings manually and they were applied, but i assume in a large
complex environment it could create some issues.

On Friday, December 9, 2016 at 7:12:16 PM UTC+2, Alexander Rilik wrote:

On Friday, December 9, 2016 at 5:22:24 PM UTC+1, Erez Zarum wrote:

  1. It doesn’t inherit puppet, puppet ca and realm proxy configuration
    from the hostgroup while it does inherit the operating system related
    configuration.

I hit this as well, but I thought it was related to the webgui! Are you
referring to this? Bug #9784: Autoprovisioning via hostgroup does not populate all parameters via WebUI or API - Discovery - Foreman

–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

–
Later,
Lukas @lzap Zapletal