Bug 798509

Created attachment 566464 [details]
The first and non-default key

Created attachment 566465 [details]
In old console page.

This happens when the user

a) creates their domain
b) creates their first key with a different name than "default"
c) attempts to delete their first key.

I believe delete should succeed here (no reason you can't have 0 keys).

broker.response: "#<Net::HTTPInternalServerError 500 Internal Server Error readbody=true>"
broker.response.body: "{\"type\":null,\"data\":null,\"version\":\"1.0\",\"messages\":[{\"field\":null,\"severity\":\"error\",\"text\":\"Failed to delete SSH key blah for user test4 due to:ERROR: Can't remove all ssh keys for user test4\",\"exit_code\":null}],\"status\":\"internal_server_error\"}"

Verify this bug on devenv-stage_139, it has been fixed now, thanks.

This issue does not always happen,but it did happen some time,so assign it back,please check it again, the following is log message:

Started POST "/app/account/keys/UUUUUUUUUUUUUU" for 203.114.244.88 at Thu Mar 01 00:42:33 -0500 2012
[Barista] Copying all javascripts
  Processing by KeysController#destroy as HTML
  Parameters: {"id"=>"UUUUUUUUUUUUUU", "authenticity_token"=>"R2fzKNJl+GXmMzQ8/pfWBBGinU2TX8dVWWQSZwb6cPc="}
Checking for logout request
Not a logout request, checking for cookie
rh_sso cookie = '0|hPQxPEgOFt0nOell3QbYP4ls43sCvBXuN0A'
User has an authenticated session
Session ticket matches current ticket
Login required
Completed 500 Internal Server Error in 1416ms

ActiveResource::ServerError (Failed.  Response code = 500.  Response message = Internal Server Error.):
  app/controllers/keys_controller.rb:44:in `destroy'

I think this issue happens when the default key is created and it's vaule it empty,just as the condition of attahcment of "In old console page",please check it.

Still has this issue , please check it.

We can allow 0 ssh keys with the domain but cli tools, java client may break during git push, creation of app(cloning repo), etc.
I can think of 2 options:

(1) Allow 0 ssh keys but update cli tools, java client to run rhc-chk or similar cmd which will inform the user about the missing ssh key during git pull/clone etc. failures.

(2) Until cli tools, java client is updated, keep at least 1 ssh key limitation and throw 403 instead of 500 error.

(1) is the right thing to do but I don't know when is the java client gets updated, what else may break without enough testing. For safer side, (2) may be desired.

FYI: To support (1), its a one line change in broker side.
     To enable 403 error in (2), broker can throw different exception to differentiate with genuine 500 errors.

We should talk to the client team.  For the CLI tools, they are calling the old API and so should still be creating a new domain with an ssh key.  The Java tools should be doing that as well.  In order to use the new REST API, both have to make a change.  When they make that change they should fix their code to handle both checking and creating the first key.  So I don't think there's a problem with #1, as long as the old API continues to work.

Fixed. Now we allow 0 ssh keys for the domain.

Verify this bug on devenv_1670, it has been fixed now, thanks.