Bug 1371231 - Re-discovering an existing host fails
Summary: Re-discovering an existing host fails
Status: CLOSED DUPLICATE of bug 1347023
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Discovery Image
Version: 6.2.0
Hardware: x86_64
OS: Linux
Target Milestone: Unspecified
Assignee: Lukas Zapletal
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2016-08-29 16:34 UTC by Reartes Guillermo
Modified: 2016-09-06 13:57 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2016-09-06 13:57:18 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1347023 0 medium CLOSED refresh_facts on a renamed discovered host creating second discovered host record 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1371226 0 unspecified CLOSED Not appending the satellite capsule port number in the 'server url' causes the wizard to loop to the begining 2021-02-22 00:41:40 UTC

Internal Links: 1347023 1371226

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:

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 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 ***

Note You need to log in before you can comment on or make changes to this bug.