Better way to skip `do_ssh_setup`?
john-karp opened this issue · comments
I'm provisioning VMs using cloud-config to install SSH keys. I set the kitchen driver settings private_key_path and ssh_key so that it can use those keys. However, during convergence kitchen-openstack then tries to do do_ssh_setup, which 1. isn't required because the keys are already installed, and 2. fails because it tries to log in using password authentication.
My workaround is that I set key_name to a dummy value, which causes do_ssh_setup to be skipped. But that seems like a hack, since there's not actually any key with that name on the openstack cluster. Is there a cleaner way?
Yeah this makes sense. I know with the openstack cluster i test with the key is already there too, so there is so need for the do_ssh_setup.
At the same time there is a possibility that there could be some clusters out there that still need the key injected in. I don't like the idea of removing this code, but at the same time maybe a feature flip around this? I'm gonna chew on it.
Maybe we should add to the README.md on how to get around this?
Could you either put in this issue exactly how you got around it, config edited and the like, or even better put a PR in to help out future people?
I think https://github.com/test-kitchen/kitchen-openstack/blob/master/lib/kitchen/driver/openstack.rb#L363 this is exactly what you want. I'll add to the README, and reference this as a possible pain point.
Added this to a PR for version 2 of the driver.
If you do key injection via
cloud-initlike this issue:
#77 the best
way is to make a "dummy-key."
I know this issue is closed but this workaround doesn't work for me as my company doesn't allow me to set up openstack keys. We need a better solution for this.
@chilicheech how do you get into your machines? username/password? odd that keys aren't allowed.
hey @jjasghar, i get into the machines by setting up ssh keys using cloud-init. When I specify a dummy key_name in the .kitchen.yml I get this error:
-----> Starting Kitchen (v1.4.2)
-----> Creating <****>...
>>>>>> Create failed on instance <****>.
>>>>>> Please see .kitchen/logs/****.log for more details
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: Expected([200, 202]) <=> Actual(400 Bad Request)
excon.error.response
:body => "{\"badRequest\": {\"message\": \"Invalid key_name provided.\", \"code\": 400}}"
:headers => {
"Content-Length" => "70"
"Content-Type" => "application/json; charset=UTF-8"
"Date" => "Wed, 11 Nov 2015 17:31:50 GMT"
}
:local_address => "*.*.*.*"
:local_port => *****
:reason_phrase => "Bad Request"
:remote_ip => "*.*.*.*"
:status => 400
:status_line => "HTTP/1.1 400 Bad Request\r\n"
>>>>>> ----------------------
If I don't specify a dummy key_name I get the following:
-----> Starting Kitchen (v1.4.2)
-----> Creating <****>...
OpenStack instance with ID of <****> is ready.
Waiting for network information to be available...
Waiting for server to be ready...
Waiting for SSH service on *.*.*.*:*, retrying in 3 seconds
root@*.*.*.*'s password:
It tries to login as root even though I've specified a transport username.
I'm at a loss here. I'll have to try to repo this, it's odd that it's falling back to root.
Can you scrub your .kitchen.yml and post it here too?
Sure, this is what my .kitchen.yml looks like. I'm gonna do some more digging as well.
---
driver:
name: openstack
openstack_username: chilicheech
openstack_api_key: my_awesome_password
openstack_auth_url: http://my_openstack_auth_url
flavor_ref: small
image_ref: rhel-6.5.7-x86_64
# key_name: dummy_key
private_key_path: /Users/chilicheech/.ssh/id_rsa
user_data: cloud_init
transport:
username: kitchen
ssh_key: kitchen_rsa
provisioner:
name: chef_zero
platforms:
- name: rhel6
suites:
- name: default
run_list:
- role[base]
Ok, got it to work. @john-karp hinted that key_name needs to be set to an empty string for it to work. maybe the docs can be updated to reflect that instead of dummy-key?
The issue with logging it attempting to log in as root was due to the fact that I had set transport: inside of driver: instead of as a sibling of driver:. This .kitchen.yml is now working for me:
---
driver:
name: openstack
openstack_username: chilicheech
openstack_api_key: my_awesome_openstack_api_key
openstack_auth_url: http://my_awesome_openstack_auth_url
require_chef_omnibus: true
image_ref: rhel7
flavor_ref: small
private_key_path: kitchen_rsa
key_name: ""
user_data: cloud_init
transport:
username: kitchen
ssh_key: kitchen_rsa
provisioner:
name: chef_zero
platforms:
- name: rhel7
suites:
- name: default
run_list:
- role[base]
Also, it seems driver: private_key_path and transport: ssh_key are redundant. Why do we need to set both? I've tried with either one or the other but it fails. Need to set both.
Yep, the driver: private_key_path and transport: ssh_key are redundant. The next release of the gem i'm deprecating the code the 1.4 TK transport layer does. I havent started that process yet, but I'll be removing it soon.
@chilicheech this good? #127
that's perfect. thanks for your help with this @jjasghar
@jjasghar
Is this still the correct way to set a key when doing cloud init? Using v3 I get:
:body => "{"badRequest": {"message": "Invalid input for field/attribute key_name. Value: . u'' is too short", "code": 400}}"
@rlewkowicz i don't think, or should i say, i havent validated against v3 yet. So I'm not sure how to help you here.
No worries, I had some confusion about the user data and cloud init so that may have been hindering my attempts. I ended up just manually adding my key and creating a snapshot. Sorry for the hassle!