Refactor #22496: Suggest new IP does not work - Smart Proxy - Foreman

Actions

Copy link

Refactor #22496

closed

Suggest new IP does not work

Added by Jeff Sparrow almost 7 years ago. Updated almost 7 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Category:

DHCP

Target version:

Difficulty:

Triaged:

Bugzilla link:

Pull request:

https://github.com/theforeman/smart-proxy/pull/567

Fixed in Releases:

Found in Releases:

Foreman - 1.16.0

Red Hat JIRA:

Description

After upgrading to 1.16 (proxy 1.15, not sure if this is the correct version as the versioning matrix has not been updated for 1.16) the option to 'suggest new ip' no longer works. It just returns the same IP. In the past, it would give a new, different IP. This proxy is using the MSFT API.

Logs dont show anything happening except the unused_ip GET api command:

D, [2018-02-01T16:35:31.635424 ] DEBUG -- : close: 100.90.128.69:51778
D, [2018-02-02T06:58:40.649263 ] DEBUG -- : accept: 100.90.128.69:47764
D, [2018-02-02T06:58:40.661266 ] DEBUG -- : Rack::Handler::WEBrick is invoked.
I, [2018-02-02T06:58:40.672266 e47d987f]  INFO -- : 100.90.128.69 - - [02/Feb/2018:06:58:40 -0600] "GET /dhcp/100.91.41.0/unused_ip HTTP/1.1" 200 22 0.0100

D, [2018-02-02T06:58:40.727270 ] DEBUG -- : close: 100.90.128.69:47764
D, [2018-02-02T06:58:44.304543 ] DEBUG -- : accept: 100.90.128.69:47766
D, [2018-02-02T06:58:44.317549 ] DEBUG -- : Rack::Handler::WEBrick is invoked.
I, [2018-02-02T06:58:44.319554 e47d987f]  INFO -- : 100.90.128.69 - - [02/Feb/2018:06:58:44 -0600] "GET /dhcp/100.91.41.0/unused_ip HTTP/1.1" 200 22 0.0020

D, [2018-02-02T06:58:44.364553 ] DEBUG -- : close: 100.90.128.69:47766
D, [2018-02-02T06:58:45.631650 ] DEBUG -- : accept: 100.90.128.69:47768
D, [2018-02-02T06:58:45.643913 ] DEBUG -- : Rack::Handler::WEBrick is invoked.
I, [2018-02-02T06:58:45.645647 e47d987f]  INFO -- : 100.90.128.69 - - [02/Feb/2018:06:58:45 -0600] "GET /dhcp/100.91.41.0/unused_ip HTTP/1.1" 200 22 0.0017

D, [2018-02-02T06:58:45.689663 ] DEBUG -- : close: 100.90.128.69:47768
D, [2018-02-02T06:58:46.563724 ] DEBUG -- : accept: 100.90.128.69:47770
D, [2018-02-02T06:58:46.575717 ] DEBUG -- : Rack::Handler::WEBrick is invoked.
I, [2018-02-02T06:58:46.577717 e47d987f]  INFO -- : 100.90.128.69 - - [02/Feb/2018:06:58:46 -0600] "GET /dhcp/100.91.41.0/unused_ip HTTP/1.1" 200 22 0.0020

D, [2018-02-02T06:58:46.621721 ] DEBUG -- : close: 100.90.128.69:47770

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Jeff Sparrow almost 7 years ago

Category could be changed to DHCP

Actions

Copy link

Updated by Anonymous almost 7 years ago

Tracker changed from Bug to Support
Project changed from Foreman to Smart Proxy
Category changed from Host creation to DHCP

Starting with 1.14 ms dhcp provider uses native MS dhcpsapi, which is also used for free ip lookups. The call will return the same ip address for as long as it is not being used.

Actions

Copy link

Updated by Jeff Sparrow almost 7 years ago

Dmitri Dolguikh wrote:

Starting with 1.14 ms dhcp provider uses native MS dhcpsapi, which is also used for free ip lookups. The call will return the same ip address for as long as it is not being used.

Doesnt that kind of defeat the purpose of "Suggest New IP"? Since its not actually new? Might as well just remove the option, no?

Actions

Copy link

Updated by Marek Hulán almost 7 years ago

Seems to work fine for other providers, Dmitri is there a difference in comparing to isc dhcp?

Actions

Copy link

Updated by Anonymous almost 7 years ago

Seems to work fine for other providers, Dmitri is there a difference in comparing to isc dhcp?

Providers (isc, remote_isc, and libvirt) that use our custom free ip tracker work as expected. All other providers that I'm aware of rely on their respective platform implementation for free ip tracking. These do not fit well with how Foreman uses this functionality in scenarios with concurrent requests for free ips. While swapping in our implementation is an option, each of these "other" platforms has their own idiosyncrasies (where addresses are coming from, use of exclude blocks, a bunch of modes that infoblox has for different operations, etc), and these need to be taken into the consideration. My plan is to go over these providers one by one to see if using our implementation for address tracking is viable.

Another option (although requiring changes on the Foreman side) is to stop requesting addresses on host creation screen, and instead retrieve them during actual host creation. Although this probably won't resolve the issue for host creation via API.

Actions

Copy link

Updated by Jeff Sparrow almost 7 years ago

The option did work with the 1.12(.13?) old school command line options. Perhaps (at least in reference to MSFT) the API works differently now?

Actions

Copy link

Updated by Anonymous almost 7 years ago

Smart-proxy's built-in address tracker relies on dhcp server state and tcp and icmp echoes for determining available addresses. One of the issues if it were to be used again with MS dhcp would be its unawareness of address exclusion ranges, which I know some people use.

Actions

Copy link