Feature #6778
open
ability to force delete existing PTR's via smart-proxy
Description
We often re-provision an environment that is on its own dedicated subnet. Occasionally we run across an old PTR, possibly due to a failed deletion of that record. Either way, the proxy has handed out the address, so we trust that it is not in use.
I would like to see a flag in the smart-proxy configuration that lets me delete existing PTR records on VM creation so that the provisioning process can continue.
Files
Updated by Dominic Cleal almost 10 years ago
Foreman should raise a conflict, then ask you to confirm that you wish to overwrite the existing DNS record?
Updated by Greg Petras almost 10 years ago
Sorry, I should have clarified that this is when using the API. Is there an option that could be passed when POSTing to /api/hosts?
Thanks,
Greg
Updated by Dominic Cleal almost 10 years ago
- Category changed from Smart Proxy to API
Ah, that makes more sense. Try setting `override: 'true'` in your hash of host attributes. It's not documented unfortunately.
Updated by Greg Petras almost 10 years ago
Dominic Cleal wrote:
Ah, that makes more sense. Try setting `override: 'true'` in your hash of host attributes. It's not documented unfortunately.
Hey Dominic. Thanks for the reply. I tried what you recommended, and got this:
unknown attribute: override (ActiveRecord::UnknownAttributeError)
See attached for the host JSON I tested with.
Updated by Dominic Cleal almost 10 years ago
Oh sorry, typo, it should have been "overwrite". You have this already in the JSON - just remove the override entry and flip overwrite to true.
Updated by Greg Petras almost 10 years ago
Dominic Cleal wrote:
Oh sorry, typo, it should have been "overwrite". You have this already in the JSON - just remove the override entry and flip overwrite to true.
Yeah I actually noticed this right after I posted it, so I gave that a try with the same JSON I posted earlier. I got this error instead:
Invalid MAC (Net::Validations::Error)
/usr/share/foreman/lib/net/validations.rb:19:in `validate_mac'
/usr/share/foreman/lib/net/dhcp/record.rb:7:in `initialize'
/usr/share/foreman/app/models/concerns/orchestration/dhcp.rb:16:in `new'
/usr/share/foreman/app/models/concerns/orchestration/dhcp.rb:16:in `dhcp_record'
/usr/share/foreman/app/models/concerns/orchestration/dhcp.rb:120:in `queue_remove_dhcp_conflicts'
/usr/share/foreman/app/models/concerns/orchestration/dhcp.rb:73:in `queue_dhcp'
[snip]
Let me know if you would like the rest of the stacktrace.
Thanks,
Greg
Updated by Dominic Cleal almost 10 years ago
Sorry for the delay. I think that's a bug in the DHCP orchestration then, which isn't taking into account when handling "overwrite" that it won't know the MAC of the VM yet. If you're willing to try something, could you edit app/models/concerns/orchestration/dhcp.rb and in queue_remove_dhcp_conflicts change the first line to:
return unless (dhcp? and overwrite? and mac.present?)
Updated by Greg Petras over 9 years ago
Dominic Cleal wrote:
Sorry for the delay. I think that's a bug in the DHCP orchestration then, which isn't taking into account when handling "overwrite" that it won't know the MAC of the VM yet. If you're willing to try something, could you edit app/models/concerns/orchestration/dhcp.rb and in queue_remove_dhcp_conflicts change the first line to:
return unless (dhcp? and overwrite? and mac.present?)
Sorry for the delay as well. I tried to comment out the line you mentioned (Foreman 1.5.3 now), and I get 'Operation FAILED: Invalid MAC'. Any other details I can provide?
Thanks for your help.
Greg
Updated by Dominic Cleal over 9 years ago
Any stack trace in the logs? You may need to enable debugging: http://projects.theforeman.org/projects/foreman/wiki/Troubleshooting#How-do-I-enable-debugging
Updated by Dominic Cleal over 9 years ago
- Related to Bug #7623: Adding kvm-guest with confilicting DNS-entry leads to failure in MAC validation added