I've encountered a similar issue. Searching for a container fails, regardless of whether the compute resource in question is internal to the satellite or on an external machine. Here's some relevant entries from /var/log/foreman/production.log:

    Processing by ImageSearchController#search_repository as TEXT
      Parameters: {"search"=>"busybox", "registry_id"=>"", "id"=>"3"}
    String does not start with the prefix 'encrypted-', so ForemanDocker::Docker this-sat was not decrypted

    Processing by ImageSearchController#search_repository as TEXT
      Parameters: {"search"=>"nginx", "registry_id"=>"", "id"=>"2"}
    String does not start with the prefix 'encrypted-', so ForemanDocker::Docker sesame was not decrypted

Created redmine issue http://projects.theforeman.org/issues/9271 from this bug

Hey Sachinji,
I have seen similar errors when the connection to compute resource is not working. We should probably not let you select a Docke rHost if the connection is not working, but that would be a different bug. Have a couple of suggestions that will tell us more from the production log as to why it exactly failed.

Uncomment the following line in 
/usr/share/foreman/config/environments/production.rb 
#config.log_level = :debug
to 
config.log_level = :debug

and then try this again. That will give us exactly why your search did not workout (if its due to bad connection or any other reason). I 'll file an issue to say new container page should not let you select a docker host that has a bad connection.

In Jeremy's case going by his logs, it looks like the failure is happening because he has been unable to connect to his docker host. So fixing the "Cant see/select bad docker host to provision to, should fix that."

Created an issue with the alernate headline ... 

http://projects.theforeman.org/issues/9365

We should handle these errors gracefully and in an informative way that explains to the user what is going on.

500 ISE is an unexpected situation when in fact, remote computing resources being unavailable, misconfigured or not supporting the requested query is highly likely and not uncommon.  

For 6.1 I'd say we trap these errors and tell user what is going and what they may do to resolve it.

Moving to POST since upstream bug http://projects.theforeman.org/issues/9271 has been closed
-------------
Anonymous
Applied in changeset commit:foreman-docker|70dd1b818ffb1f9d812ad69f04a2f941e24451a0.

Verified with snap11/RC5. (Satellite-6.1.0-RHEL-7-20150407.1).

case 1: when docker compute-resource is correctly configured. I can search the image from new container page. Please see the screenshot.

Created attachment 1012111 [details]
success on seraching image from new container page

when no docker type compute-resource is defined then on selecting new container, UI says:

"You need a Docker compute resource in order to create containers. Please add a new one and try again."

case3: In case we set incorrect docker host, getting error:

An error occured during repository search: 'getaddrinfo: Name or service not known (SocketError)'

along with NetworkError: 500 Internal Server Error - https://host_name/image_search/5/auto_complete_repository_name?search=b&registry_id="

I think we can raise here more user friendly error when docker host is not reachable as per comment 5 and 7.

Created attachment 1012124 [details]
when docker_host is not reachable, image search on new container page fails with error: 'getaddrinfo: Name or service not known (SocketError)'

I'd say the above error handling is acceptable, 'getaddrinfo: Name or service not known (SocketError)' is a fairly standard error message indicating that the hostname can not be resolved.

We correctly show this error in the error dialog.

Perhaps it could be a bit more friendly and state that the user should check the Hostname/URL for the compute resource but we are at least trapping the condition and showing the error to the user.

For 6.1 I'd argue this is acceptable.

verified with sat6.1.1 GA snap13. As per comment 16, 'getaddrinfo: Name or service not known (SocketError)' is a standard error, so moving this verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2015:1592