Description of problem: The user's handle on IRC is gomix. Here's the out put to rhc domain show: ----- User Info ========= Namespace: gomix RHLogin: ggomix Application Info ================ eeb326193 Framework: diy-0.1 Creation: 2012-06-28T11:53:54-04:00 UUID: eddf1421fdef4708a5019ae033276ebc Git URL: ssh://eddf1421fdef4708a5019ae033276ebc.com/~/git/eeb326193.git/ Public URL: http://eeb326193-gomix.rhcloud.com/ Embedded: None ----- Here's the output to rhc app create: ----- rhc app create -a eeb3 -t diy-0.1 -d Password: ********** Submitting form: rhlogin: ggomix debug: true Contacting https://openshift.redhat.com Creating application: eeb3 in gomix Contacting https://openshift.redhat.com There was a problem communicating with the server. Response message: Timeout::Error If you were disconnected it is possible the operation finished without being able to report success. You can use 'rhc domain show' and 'rhc app status' to learn about the status of your user and application(s). ----- The workaround was to add --timeout 300 (user is happy) Please note: The bad part to the timeout was that the app was created but without a DNS entry leaving an app that wasn't reachable.
Timeout that results in no DNS is a broker issue.
Cannot reproduce this issue. Going through production logs to find out what may have really happened. It may be a one time problem with Dynect. Also, its not clear whether the DNS was never good, or is it just that it was not resolvable in reasonable time. (we have incidents where DNS took 5 minutes to resolve).
We are continually working to make app creates faster but I am not seeing anything we can do to address this particular concern. The longer term solution will be to background gear create and return immediately to the client. But that's being handled with longer term user stories. If we aren't getting most requests done in the normal timeout then we can certainly increase it. But I am not hearing a lot of complaints about timeouts.