Bug 1371231

Summary: Re-discovering an existing host fails
Product: Red Hat Satellite Reporter: Reartes Guillermo <greartes>
Component: Discovery ImageAssignee: Lukas Zapletal <lzap>
Status: CLOSED DUPLICATE QA Contact:
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.2.0CC: bbuckingham, bkearney, jcallaha
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-09-06 13:57:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Reartes Guillermo 2016-08-29 16:34:02 UTC
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'
 | 
 |

Comment 2 Lukas Zapletal 2016-09-06 13:57:18 UTC
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 ***