Bug #6916
closed
Added by Oliver Weinmann over 10 years ago.
Updated about 8 years ago.
Description
Hi,
just updated to Foreman 1.5.2 today as I already had issues with 1.5.1 deploying hosts. Sometimes that host creation took ages to complete. I guess this is because our MS DHCP has more than 3 subnets and already many reservations. On our DMZ MS DHCP this works fine. Just one subnet and not so many reservations.
Now I get this error with 1.5.2:
Create DHCP Settings for gedasvl10.a.space.corp task failed with the following error: ERF12-6899 [ProxyAPI::ProxyException]: Unable to set DHCP entry ([RestClient::RequestTimeout]: Request Timeout) for proxy https://gedasvw16.a.space.corp:8443/dhcp
To me it looks like the whole MS DHCP smart-proxy thing would need to be changed to get around this error as it only happens when there are many subnets and reservations on the MS DHCP.
Oliver Weinmann wrote:
Hi,
just updated to Foreman 1.5.2 today as I already had issues with 1.5.1 deploying hosts. Sometimes that host creation took ages to complete. I guess this is because our MS DHCP has more than 3 subnets and already many reservations. On our DMZ MS DHCP this works fine. Just one subnet and not so many reservations.
Now I get this error with 1.5.2:
Create DHCP Settings for gedasvl10.a.space.corp task failed with the following error: ERF12-6899 [ProxyAPI::ProxyException]: Unable to set DHCP entry ([RestClient::RequestTimeout]: Request Timeout) for proxy https://gedasvw16.a.space.corp:8443/dhcp
To me it looks like the whole MS DHCP smart-proxy thing would need to be changed to get around this error as it only happens when there are many subnets and reservations on the MS DHCP.
We too are seeing this issue and it is impacting our deployment. Should we downgrade to 1.5.1 ?
Bump. The same issue.
It seems like the proxy readds all subnets upon addition of single server to Foreman, causing the proxy to timeout eventually, when number of hosts grows.
Also impacting our deployments, so if it's not fixable, we'll be forced to switch to Cobbler.
did you consider limiting the subnets you are interested in, this should reduce greatly the amount of time.
Ruslan Kiianchuk wrote:
Also impacting our deployments, so if it's not fixable, we'll be forced to switch to Cobbler.
How would that solve the issue? after all, cobbler does not manage windows dhcp, if you can switch to a non windows dhcp server then this issue is also not relevant afaiu?
Ohad Levy wrote:
did you consider limiting the subnets you are interested in, this should reduce greatly the amount of time.
I limited it to only two subnets. But the subnets are quite big /22. The proxy has become totally unusable for us. A fix would be really appreciated. We can't switch to a Linux DHCP. :( I'm happy to help solving the problem. But my ruby programming skills are absolutely zero. I can test and report if that is ok. I can sign in on IRC...
Ok, it creates the dhcp reservation when it runs into a timeout. Clicking on submit again will fail with another error. I then deleted the DHCP reservation on the windows server and submitted it again and after approx 2-3 minutes it works... sometimes. So yes it is ridicously slow and you have to be lucky that it works...
We see this with ISC DHCP as well, as it iterates over every single subnet/server when you are only adding a single server. This is really bad at any sort of scale :(
- Related to Bug #7766: ms_native dhcp smart proxy code scales poorly added
I am having this issue as well, with isc-dhcp-server. Getting timeout while creating reservation. Worked well with a couple of subnets in dhcp.yml, but now with four subnets, one of them is a /21, the proxy is not working. Is there a way to change the timeout setting in order to work around the problem?
This also applies to 1.8. I have changed the timeout setting and now the provisioning works 100% but the dhcp thing still takes about 100 sec to complete.
Hi,
since upgrading to 1.8.1 and then 1.8.2 the whole windows smart proxy has become totally unusable. I only manage one /22 subnet and CPU usage stays at 100%. I guess the whole windows smart-proxy needs to be re-written. Netsh commands are not really fast. Maybe some Powershell CMDlets can help?
- Status changed from New to Ready For Testing
- Pull request https://github.com/theforeman/smart-proxy/pull/306 added
- Pull request deleted (
)
- Related to Refactor #11866: Replace linear searches in various lookups in DHCP module with constant-time lookups. added
- Status changed from Ready For Testing to New
- Pull request added
- Pull request deleted (
https://github.com/theforeman/smart-proxy/pull/306)
- Status changed from New to Resolved
Ms dhcp provider has been re-written and the issue should be resolved now. I'm going to close the ticket, please re-open it if you continue to experience the problem with the new version of the provider.
Also available in: Atom
PDF