Bug 878171 - git clone fails for app on an account with multiple ssh keys - write_ssh_keys method in Node unix_user.rb is not thread safe
Summary: git clone fails for app on an account with multiple ssh keys - write_ssh_keys...
Keywords:
Status: CLOSED DUPLICATE of bug 876942
Alias: None
Product: OKD
Classification: Red Hat
Component: Containers
Version: 2.x
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Rob Millner
QA Contact: libra bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-19 19:31 UTC by Ram Ranganathan
Modified: 2015-05-14 23:02 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-11-19 19:52:25 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Ram Ranganathan 2012-11-19 19:31:27 UTC
Description of problem:
In the node code - lib/openshift-origin-node/model/unix_user.rb - the write_ssh_keys method is not thread safe. 


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

How reproducible:
Often (on INT)


Steps to Reproduce:
1. Create an account on integration
2. Add 2 different ssh keys to the account
3. In a loop - create and destroy scalable apps till the git clone fails.
  
Actual results:
Fails to clone the git repository because the ~/.ssh/authorized_keys is hosed.


Expected results:
git clone should succeed + keys should be valid. 

Additional info:
The broker creates the gear and then issues parallel mcollective calls to add the authorized ssh keys to the gear. On a slow system, its possible to have the 2 parallel ssh key operations running simultaneously and this results in the 
~/.ssh/authorized_keys file getting borked.

Comment 1 Ram Ranganathan 2012-11-19 19:34:41 UTC
Workaround:  Remove all the keys from the account and re-add the keys.
Can FutureFeature this but keep the pri/sev higher.

Comment 2 Rob Millner 2012-11-19 19:52:25 UTC
This issue was worked around in BZ 876942 by disabling the parallel thread execution and a user story was created to put it back in.

*** This bug has been marked as a duplicate of bug 876942 ***


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