Feature #944
closed
Provide a mechanism to clear a host's network conflicts
Description
If a host fails to build because there are network conflicts, e.g. there is already a DNS entry for this host, then provide a way to resolve the problem.
Updated by Paul Kelly almost 13 years ago
- Status changed from New to Ready For Testing
- Assignee set to Paul Kelly
Updated by Paul Kelly almost 13 years ago
I have pushed the branch to my github as I added your requests as a separate commit, for easy viewing.
Updated by Paul Kelly over 12 years ago
Another complete rewrite but this time I think you will like it
I have not extensively tested it but see if the code is suitable before I expend all that time
Updated by Paul Kelly over 12 years ago
- Category set to Orchestration
- Assignee changed from Paul Kelly to Ohad Levy
Updated by Paul Kelly over 12 years ago
A new implementation is on the way. A couple of point might make this code more easy to understand.
1 I had to reorder the DNS and DHCP operations so that DNS went first. This is because conflict in DNS validations would cause the queue to never get run and DHCP conflicts would never be tested for. If DNS conflicts are detected then a DHCP collision test is performed. This is only done when there are DNS collisions or if we are forcing foreman to overwrite the network data as this is a slooooow operation for native MS.
2) When overwriting the network data we do not consider collisions as fatal errors
One other point; I cannot think of any suitable name for this operation
overwrite? ? errors.are_all_conflicts? : errors.empty?If you can, then please refactor the damn thing.
Updated by Paul Kelly over 12 years ago
Added support for conflicting DHCP leases and for displaying conflict errors in the GUI
Updated by Paul Kelly over 12 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset 117ba92a758e4589ef5fdf1f1b9083402b2d317b.
Updated by Ohad Levy over 12 years ago
- Status changed from Closed to Assigned
- Assignee changed from Ohad Levy to Paul Kelly
sadly i've reverted this patch as well, it seems like it breaks the orchestation code, and I had little time to dig in.
in general, I think we need to break down the methods that decided if a task needs to be triggered or not, I've seen some examples (with the patch applied) where some tasks / rollback tasks are still performed even if there are errors etc.
I would suggest something like:
def in_rollback?
queue.tasks.select{|t| t.type == "rolebacked"}.any?
end
def allowed_to_add_new_tasks? .. end
etc
Updated by Ohad Levy over 12 years ago
- Status changed from Assigned to Closed
Applied in changeset ac36e7ce627de142961b22fca57db9d6412b9aa1.
Updated by Ohad Levy over 12 years ago
- Status changed from Closed to New
as this was reverted, the ticket is reopened
Updated by Ohad Levy about 12 years ago
- Status changed from New to Closed
Applied in changeset 30ae12bf50633dde28d785e0f8fe9bbbc497c76f.