Bug 827437 - OpenShift application setup process generated generic Rails error message, setup process is non-intuitive, ssh setup sub-optimal for OS X
OpenShift application setup process generated generic Rails error message, se...
Product: OpenShift Origin
Classification: Red Hat
Component: Website (Show other bugs)
All All
medium Severity low
: ---
: ---
Assigned To: Clayton Coleman
libra bugs
: FutureFeature, Triaged
Depends On:
  Show dependency treegraph
Reported: 2012-06-01 09:36 EDT by Gary Weaver
Modified: 2015-05-14 21:11 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-11-19 13:03:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Gary Weaver 2012-06-01 09:36:38 EDT
Description of problem:

See https://openshift.redhat.com/community/forums/openshift/got-im-sorry-but-something-went-wrong-error-when-trying-to-create-new-jboss-as-71

Got generic Rails error (see discussion in thread): I'm sorry, but something went wrong

Version-Release number of selected component (if applicable):

How reproducible:

Create a new application in OpenShift JBoss AS 7.1, etc.

Steps to Reproduce:
1. Go to OpenShift site
2. Use web interface to request new account for JBoss AS 7.1 application (with new namespace).
3. Get generic Rails error.
4. Email is sent to me saying all is setup and how I can visit the application.
5. Go back and see git repo info when click on application.
6. Attempt to git clone in OS X terminal window times out and because there was no indication that needs to be setup per Getting Started doc which is not mentioned prominently in the web interface on the page that provides the git repo info.
7. Browse around and find and visit link to OpenShift URL that uses the application I created that has not been uploaded. 
8. Attempt to visit site fails because not setup.
Actual results:

Even though application information is there in OpenShift web console, the application is not setup. In addition, get generic Rails error during setup.

Expected results:

OpenShift web console and email should not indicate all is ready to go when it isn't. Web console should not give generic rails error and should walk user step-by-step through the setup process. In addition, in Getting Started doc, OS X requires two Ruby gems which is not a good idea considering the RVM is very well-used now and you neither know what version of Ruby you are using or where the gems are installed, and sudo should not be used for RVM gem installs. In addition, the .ssh/config changes made by that second gem look a little loose. Instead, OpenShift should provide a GitHub like walkthrough of creating id_rsa public key and pasting it into web interface provided by OpenShift (please see GitHub as they also provide command to copy/paste key directly CLI/terminal.app which was important as I had a copy/paste issue when I tried to do it myself before).

Additional info:

Comment 1 Clayton Coleman 2012-06-04 01:14:57 EDT
We've got a bunch of new changes landing this week - for the SSH config setup, the first time you run the 'rhc' command or whenever you run 'rhc setup' it will walk you through uploading your keys.  In addition, we'll try and get the UI fixed so that on the application overview page when you don't have a key setup you see a message vs. seeing the git url.
Comment 2 Gary Weaver 2012-06-04 09:25:29 EDT

What do you think of the two ideas:

* Maybe the Ruby dependency for OS X just to enable Git repo access is a bad idea: Ruby is included in OS X, but most modern Ruby/Rails developers are using rvm and installing a gem to be available everywhere could be a bit of a support issue unless you tell them how to install to the @global gemset, so you have to say that, but then you realize that a good part of the community may not even need Ruby for their development (like for a Java EE 6 OpenShift app), so you're wasting a good bit of time trying to explain that setup, when it shouldn't be needed.

* Manage the ssh keys like GitHub via having a web interface that allows you to copy/paste your key to allow additional computers to access your Git repo. (This makes me feel a lot more secure than what I saw being done in the ssh OpenShift setup.)

I know that this is different than your current direction with these things, but as someone new to OpenShift, it just wasn't obvious to me why it needed to be as complex as it was just to clone a Git repo to start working on a Java EE 6 app in OS X.

Thanks for your consideration!

Comment 3 Clayton Coleman 2012-06-04 10:12:34 EDT
Gary - I believe we had that section in there because Ruby might not be installed by default on a Mac.  We needed a simple step to get there which was either xcode (on the CD) or git for OS X (download).  I'll take a look at simplifying that down.

The "My Account" page should allow you to copy/paste your key, and when you create an application you should see a section to paste the key.
Comment 4 Gary Weaver 2012-06-04 13:09:28 EDT

Thanks! That helps to know where I could copy/paste the key. It would be nice if that were a guided part of setup and couldn't be missed.

For my first point in last comment, I should maybe restate that as:

Has it been considered to not require Ruby for a developer in OS X to get setup in OpenShift and push a Java EE 6 application to OpenShift to be hosted?

For example, in https://openshift.redhat.com/app/getting_started it is stated to have root access and do this:

$ sudo gem install json_pure
$ sudo gem install rhc

But that doesn't work for everyone. Before RVM, then info provided such as that from Matt Hicks here was accurate: https://openshift.redhat.com/community/forums/express/rhc-create-domain-command-not-found

But with RVM which is very-well used now, you would need to decide whether you would want to put it in a local gemset to whatever version of Ruby is currently active (which could change if you have .rvmrc's in various directories) similar to what one of the members of the openshift team mentioned in http://stackoverflow.com/questions/10111020/cant-use-rhc-after-installation-for-openshift or if you were a typical openshift

Instead, maybe you would want to install to RVM's global gemset to have it available to multiple gemsets with that version of Ruby: https://rvm.io//gemsets/global/

Or still better, maybe you want to put json_pure and rhc into ~/.rvm/gemsets/global.gems so that everytime you create a gemset regardless of the Ruby version or gemset, it will try to install those two into it as mentioned here:

But that doesn't solve the gems needing to be there when you only have system ruby and not one of RVM's rubies. And even for a system-wide Ruby, there's not only OS X's, but maybe Homebrew, MacPorts, or Fink installed it, etc. These may or may not require sudo.

Because of this, requiring Ruby gems at command-line for a non-Ruby project can end up potentially causing a lot more support issues than it is probably worth, at least for a non-Ruby project. In this case, I was just trying to create a Java EE 6 application, it really seemed like additional overhead to need gems to be able to push something to a Git repo.

I personally think that the fewer requirements you have like that, the more adoption there will be.


Comment 5 Gary Weaver 2012-06-04 13:12:05 EDT
oops: please ignore the "or if you were a typical openshift" and other errors in that last comment. Got distracted when I was editing it. :)
Comment 6 Clayton Coleman 2012-06-15 12:55:07 EDT
Gary, thanks for your feedback.  Unfortunately it would be a huge effort to move away from Ruby for the CLI, so it's not a practical option for us for a while.  The console and JBoss Dev Studio (https://openshift.redhat.com/community/developers/tools) will try to fill the gap for folks who have the issues.  I think most of the Ruby issues are solvable on many platforms (anyone using RVM for example I would expect would have the ability to debug most gem install issues), and we want to keep simplifying and reducing our external dependencies as much as possible.  

Sudo vs. non-sudo is definitely an annoying issue, especially given that there is no standard recommendation.  We had recently looked into a wgettable script which would handle many of these automatic decisions, but it's not available on all operating systems so we're a bit limited there unless we make more effort

json_pure is no longer required and we've switched to a more standard set of gems.  The binpath issue is one we should highlight more in our documentation, and the rvm issue is one we really haven't dug into.  That's something I can target with this bug specifically
Comment 7 Gary Weaver 2012-06-15 14:50:19 EDT
Clayton, thanks for the response and explanation. I thought it would probably not be feasible to change from the current way of doing things, but wanted to provide first impressions since my guess is that many who are evaluating OpenShift will be developers, and perhaps some of them will have a similar experience.

Look forward to any changes you implement in the future to make it easier, more secure, and less invasive to those using OS X, Ruby, and RVM.
Comment 8 Clayton Coleman 2012-11-19 13:03:06 EST
As an update on this bug, we've added RVM specific steps here, https://openshift.redhat.com/community/developers/install-the-client-tools#rvm, and also vendored a few problematic gems.

Don't have any easy solution to the sudo story right now but a curlable wgettable script would help ease the pain.  I've opened https://github.com/openshift/rhc/issues/230 to track that in case someone in the community wants to get involved before we get around to it.

Closing this as UPSTREAM because the sudo issue is separate are broader than the scope of the defect - hopefully we've at least addressed most of the issues brought up in this defect (rhc setup displays info about the keys it will use, the console is more up front about SSH access now).

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