Discovery and disjoint subnet/dhcp ranges

So, i've been playing with discovery a bit, and am getting ready to
hopefully use it in a few hundred node bare metal deploy soon. However,
hitting a bit of a wall right now…first my setup:

  • Got a network hosts using discovery will be on. lets say its
    192.168.1.0/24.
  • DHCP (which in this case is infoblox, but, it shouldn't mater AFAIK), is
    setup with a dhcp range for 192.168.1.200->192.168.1.254.
  • Subnet is defined in foreman, with the smart proxy managing it. Optional
    start/end of IP address range there is 192.168.1.5->192.168.1.199. So, as
    per the docs, disjoint.
  • Discovery rule setup for hosts come from this network/subnet

My understanding would be that the following should happen:
node boots, PXE kicks in, it leases and address from the high range
(200->254). Downloads discovery image. Boots it, sends facts.
Foreman get facts, I click auto-provision.

This is where it goes off the rails a bit…

I would expect foreman to now select an IP from the defined range (5->199),
send that to the proxy to get put into dns, name the host accordingly (I'm
naming based on ip), and reboot the host.

What happens is the host gets assigned the same IP it booted with(from the
DHCP defined range, not the one foreman has been told about), and the
hostname is based off of that.

This give me a couple problems:
1). That upper range will fill up with reservations, eventually leaving no
leases in the range for new hosts to use for discovery.
2). Sadly, infoblox, when creating records inside a dhcp range, needs a
restart. So until that happens those records (which i don't want anyways)
aren't "live".

What I've done to rule a few things out:
Started with direct discovery (no smart proxy plugin for discovery), and
with IPAM for the subnet set to DHCP.
Tried swapping to a smart-proxy discovery provider, no change, other than
now the smart-proxy is being used(which is a good thing).
Tried switching the IPAM setting to internal, hoping foreman would then
honor the IP range setting(s), no change.

So this leave me asking…uh, what?

Is this…expected behavior? Should the discovery provisioning process be
re-using the IP used in the first phase, or should it be asking for a new
one? (if i click provision and then go into the interface and have it
suggest a new IP, it gets it from the right range)

help?

Matt

So I did a bit more digging today, to no real success. (maybe this should
goto -dev? )

I found my infoblox dhcp plugin wasn't paying any attention to the
from_ip_address and to_ip_address when finding unused ips, and fixed that,
but I was pretty sure that wasn't the issue, and as expected, it didn't
change this behavior.

From cranking up the logs to debug, when provisioning a discovered host, I
never see the "unsued ip" proxy request come in…

Finally, digging into the discovery code a bit, it looks like the class
ForemanDiscovery::HostConverter is whats doing the actual creation of a
host, and since that just converts the discovered host object into a
managed host, no change in hostname/ip/etc is done.

help?

Is this by designed? How does this take into account the disjoint dhcp
scope as recommended by the docs?

··· On Thursday, June 16, 2016 at 3:29:06 PM UTC-4, Matt wrote: > > So, i've been playing with discovery a bit, and am getting ready to > hopefully use it in a few hundred node bare metal deploy soon. However, > hitting a bit of a wall right now...first my setup: > > * Got a network hosts using discovery will be on. lets say its > 192.168.1.0/24. > * DHCP (which in this case is infoblox, but, it shouldn't mater AFAIK), is > setup with a dhcp range for 192.168.1.200->192.168.1.254. > * Subnet is defined in foreman, with the smart proxy managing it. Optional > start/end of IP address range there is 192.168.1.5->192.168.1.199. So, as > per the docs, disjoint. > * Discovery rule setup for hosts come from this network/subnet > > My understanding would be that the following should happen: > node boots, PXE kicks in, it leases and address from the high range > (200->254). Downloads discovery image. Boots it, sends facts. > Foreman get facts, I click auto-provision. > > This is where it goes off the rails a bit... > > I would expect foreman to now select an IP from the defined range > (5->199), send that to the proxy to get put into dns, name the host > accordingly (I'm naming based on ip), and reboot the host. > > What happens is the host gets assigned the same IP it booted with(from the > DHCP defined range, not the one foreman has been told about), and the > hostname is based off of that. > > This give me a couple problems: > 1). That upper range will fill up with reservations, eventually leaving no > leases in the range for new hosts to use for discovery. > 2). Sadly, infoblox, when creating records inside a dhcp range, needs a > restart. So until that happens those records (which i don't want anyways) > aren't "live". > > What I've done to rule a few things out: > Started with direct discovery (no smart proxy plugin for discovery), and > with IPAM for the subnet set to DHCP. > Tried swapping to a smart-proxy discovery provider, no change, other than > now the smart-proxy is being used(which is a good thing). > Tried switching the IPAM setting to internal, hoping foreman would then > honor the IP range setting(s), no change. > > So this leave me asking...uh, what? > > Is this..expected behavior? Should the discovery provisioning process be > re-using the IP used in the first phase, or should it be asking for a new > one? (if i click provision and then go into the interface and have it > suggest a new IP, it gets it from the right range) > > > help? > > Matt > >

Actually, I'm now wondering if I'm simple mis-understanding the
docs…after re-reading this a few times (as well as asking a co-worker to
double check me):
<quote>

While it is possible to define the same DHCP range in Foreman, it’s usually
good practice to select a range from outside the pool defined in the
installer, but still in the subnet. For the example above, it is
recommended to define the DHCP range from 10.0.0.1 to 10.0.0.99 in the
Foreman UI which gives the following IP address distribution:

  • 10.0.0.1 - 10.0.0.99 - addresses reserved during bare-metal
    provisioning by Foreman
  • 10.0.0.100 - 10.0.200 - addresses for dynamic clients in the subnet
    (discovered hosts, unmanaged hosts)

</quote>

My assumption was that a discovered host would do its discovery in the
10.0.0.100-200 range, then be provisioned, just like any other host, into
the 10.0.0.1-99 range. Now i'm wondering if the intent the whole time was
for discovered hosts to always remain in that discovery range?

··· On Fri, Jun 17, 2016 at 2:28 PM Matt wrote:

So I did a bit more digging today, to no real success. (maybe this should
goto -dev? )

I found my infoblox dhcp plugin wasn’t paying any attention to the
from_ip_address and to_ip_address when finding unused ips, and fixed that,
but I was pretty sure that wasn’t the issue, and as expected, it didn’t
change this behavior.

From cranking up the logs to debug, when provisioning a discovered host, I
never see the “unsued ip” proxy request come in…

Finally, digging into the discovery code a bit, it looks like the class
ForemanDiscovery::HostConverter is whats doing the actual creation of a
host, and since that just converts the discovered host object into a
managed host, no change in hostname/ip/etc is done.

help?

Is this by designed? How does this take into account the disjoint dhcp
scope as recommended by the docs?

On Thursday, June 16, 2016 at 3:29:06 PM UTC-4, Matt wrote:

So, i’ve been playing with discovery a bit, and am getting ready to
hopefully use it in a few hundred node bare metal deploy soon. However,
hitting a bit of a wall right now…first my setup:

  • Got a network hosts using discovery will be on. lets say its
    192.168.1.0/24.
  • DHCP (which in this case is infoblox, but, it shouldn’t mater AFAIK),
    is setup with a dhcp range for 192.168.1.200->192.168.1.254.
  • Subnet is defined in foreman, with the smart proxy managing it.
    Optional start/end of IP address range there is 192.168.1.5->192.168.1.199.
    So, as per the docs, disjoint.
  • Discovery rule setup for hosts come from this network/subnet

My understanding would be that the following should happen:
node boots, PXE kicks in, it leases and address from the high range
(200->254). Downloads discovery image. Boots it, sends facts.
Foreman get facts, I click auto-provision.

This is where it goes off the rails a bit…

I would expect foreman to now select an IP from the defined range
(5->199), send that to the proxy to get put into dns, name the host
accordingly (I’m naming based on ip), and reboot the host.

What happens is the host gets assigned the same IP it booted with(from
the DHCP defined range, not the one foreman has been told about), and the
hostname is based off of that.

This give me a couple problems:
1). That upper range will fill up with reservations, eventually leaving
no leases in the range for new hosts to use for discovery.
2). Sadly, infoblox, when creating records inside a dhcp range, needs a
restart. So until that happens those records (which i don’t want anyways)
aren’t “live”.

What I’ve done to rule a few things out:
Started with direct discovery (no smart proxy plugin for discovery), and
with IPAM for the subnet set to DHCP.
Tried swapping to a smart-proxy discovery provider, no change, other than
now the smart-proxy is being used(which is a good thing).
Tried switching the IPAM setting to internal, hoping foreman would then
honor the IP range setting(s), no change.

So this leave me asking…uh, what?

Is this…expected behavior? Should the discovery provisioning process be
re-using the IP used in the first phase, or should it be asking for a new
one? (if i click provision and then go into the interface and have it
suggest a new IP, it gets it from the right range)

help?

Matt


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.

> My assumption was that a discovered host would do its discovery in the
> 10.0.0.100-200 range, then be provisioned, just like any other host, into
> the 10.0.0.1-99 range. Now i'm wondering if the intent the whole time was
> for discovered hosts to always remain in that discovery range?

It looks like you've found a bug, it's that easy :slight_smile:

Please file a ticket, I think the solution is to simply blank the IP
address while provisioning to let the orchestration to provide the
correct one. I suggest to add a global setting option in order to
explicitly enable the old behavior since it's with us from the very
beginning and someone might expect it for the future.

··· -- Later, Lukas #lzap Zapletal

Ha, simple enough!

Ticket filed: Feature #15468: Make new reservations for all interfaces during provisioning - Discovery - Foreman

··· On Mon, Jun 20, 2016 at 8:05 AM Lukas Zapletal wrote:

My assumption was that a discovered host would do its discovery in the
10.0.0.100-200 range, then be provisioned, just like any other host, into
the 10.0.0.1-99 range. Now i’m wondering if the intent the whole time was
for discovered hosts to always remain in that discovery range?

It looks like you’ve found a bug, it’s that easy :slight_smile:

Please file a ticket, I think the solution is to simply blank the IP
address while provisioning to let the orchestration to provide the
correct one. I suggest to add a global setting option in order to
explicitly enable the old behavior since it’s with us from the very
beginning and someone might expect it for the future.


Later,
Lukas #lzap Zapletal


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.