Description of problem: For some reason the provision process is aborted and the host entry is not deleted from discovred hosts by the admin The admin now tries again to provision the same host (but he forgot to delete its entry from discovered hosts from a previous attemprt) Once he answers all prompts, the wizard TUI loops back to the begining without issuing any error or message. An error was issued, but on another virtual terminal. Version-Release number of selected component (if applicable): * Sat 6.1.2 * foreman-discovery-image-3.1.1-16.el7sat.noarch How reproducible: Always Steps to Reproduce: 1. boot with the iso foreman-discovery-image-3.1.1-16.el7sat 2. select nic, select static, setup the network 3. enter the server url (https://sixthsat1.example.com:9090) 4. select proxy 5. it says 'success' and the entry is shown in 'discovered hosts' on the Satellite 6. poweroff the server. 7. retry steps 1-4 8. the wizard TUI loops to the first dialog. Actual results: The wizard TUI does not tel the user that a previous entry in 'discovered hosts' is still there. The admin must delete it manually, but the wizard TUI do not inform the admin of what is happening, it just starts again. An error is shown, but on another virtual terminal. Expected results: The wizard TUI should tell the admin something like "a prevoious entry exists in discovered hosts, please, delete it firt and then retry." If one deletes the entry from discovered hosts and then retries, it will work ok. Additional info (production.log): 2016-08-29 13:19:51 [app] [I] Started POST "/discovery/create" for 192.168.205.99 at 2016-08-29 13:19:51 -0300 2016-08-29 13:19:51 [app] [F] | ActionController::RoutingError (No route matches [POST] "/discovery/create"): | actionpack (4.1.5) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call' | actionpack (4.1.5) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call' | railties (4.1.5) lib/rails/rack/logger.rb:38:in `call_app' | railties (4.1.5) lib/rails/rack/logger.rb:22:in `call' | actionpack (4.1.5) lib/action_dispatch/middleware/request_id.rb:21:in `call' | rack (1.5.2) lib/rack/methodoverride.rb:21:in `call' | rack (1.5.2) lib/rack/runtime.rb:17:in `call' | activesupport (4.1.5) lib/active_support/cache/strategy/local_cache_middleware.rb:26:in `call' | actionpack (4.1.5) lib/action_dispatch/middleware/static.rb:64:in `call' | actionpack (4.1.5) lib/action_dispatch/middleware/static.rb:64:in `call' | rack (1.5.2) lib/rack/sendfile.rb:112:in `call' | railties (4.1.5) lib/rails/engine.rb:514:in `call' | railties (4.1.5) lib/rails/application.rb:144:in `call' | railties (4.1.5) lib/rails/railtie.rb:194:in `public_send' | railties (4.1.5) lib/rails/railtie.rb:194:in `method_missing' | rack (1.5.2) lib/rack/builder.rb:138:in `call' | rack (1.5.2) lib/rack/urlmap.rb:65:in `block in call' | rack (1.5.2) lib/rack/urlmap.rb:50:in `each' | rack (1.5.2) lib/rack/urlmap.rb:50:in `call' | /usr/share/gems/gems/passenger-4.0.18/lib/phusion_passenger/rack/thread_handler_extension.rb:77:in `process_request' | /usr/share/gems/gems/passenger-4.0.18/lib/phusion_passenger/request_handler/thread_handler.rb:140:in `accept_and_process_next_request' | /usr/share/gems/gems/passenger-4.0.18/lib/phusion_passenger/request_handler/thread_handler.rb:108:in `main_loop' | /usr/share/gems/gems/passenger-4.0.18/lib/phusion_passenger/request_handler.rb:441:in `block (3 levels) in start_threads' | logging (1.8.2) lib/logging/diagnostic_context.rb:323:in `call' | logging (1.8.2) lib/logging/diagnostic_context.rb:323:in `block in create_with_logging_context' | |
Thanks, we are aware of this and this will be fixed in 6.3. This was fixed in http://projects.theforeman.org/issues/15368 See also https://bugzilla.redhat.com/show_bug.cgi?id=1347023 *** This bug has been marked as a duplicate of bug 1347023 ***