Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fog:Rackspace uses servers#create, which only allows a key name #130

Open
martinb3 opened this issue Oct 4, 2015 · 3 comments
Open

fog:Rackspace uses servers#create, which only allows a key name #130

martinb3 opened this issue Oct 4, 2015 · 3 comments

Comments

@martinb3
Copy link
Contributor

martinb3 commented Oct 4, 2015

Hey! So I'm working on a PR that adds a Rax-specific example of this driver, and I've tripped over something. This driver uses servers#create which requires a named keypair already be created on the account.

Taking a survey of what other tools use to create nodes at Rackspace using fog, I found two different behaviors:

  • knife-rackspace uses passworded SSH with an optional ability to provide a key name, but you must create the key yourself (not unlike the requirement currently in chef-provisioning-fog)
  • kitchen-rackspace actually uses fog's other way to create Rackspace instances, servers#bootstrap, which actually uses SSH to get a public key on the server.

I also found that the fog Rackspace compute v1 provider had a similar bootstrap implementation.

It seems like the recommended 'fog best practice' way to bootstrap a Rackspace server using SSH keys is to use the bootstrap method, according to their docs. chef-provisioning-fog currently uses the create server method. I'm not sure this is an urgent fix, but I wanted to at least raise an issue so folks who try to do what I did are aware.

martinb3 added a commit to martinb3/chef-provisioning-rackspace-example that referenced this issue Oct 4, 2015
@jjasghar
Copy link
Contributor

@martinb3 when you get some time in the near future mind syncing with me on this? I don't think this is still relevant, but I'd like to confirm.

@martinb3
Copy link
Contributor Author

Hey sure! I'm not sure which way is the right answer here, though. @mdarby do you have any thoughts about which is better?

@mdarby
Copy link

mdarby commented Feb 25, 2016

I don't honestly; I'd be concerned about breaking existing libs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants