knife openstack server create fails on Windows2012r2 on WinRM connection

[brandonjbjelland]

I'm trying to tie together the workflow of launching, joining a domain (via userdata & restart), and bootstrapping a Windows2012r2 host within openstack through knife but I'm running into issues. I can do this same process through a sequential nova boot and knife bootstrap against the node but I'd rather do it through knife openstack server create as it wraps this process in one tidy command.

Combining flags from the two commands into the server create the host spins up heathy and runs through the user-data as expected but in establishing a winRM connection, it hangs:

knife openstack server create -f 3 --image 68fbafa1-106d-4195-8e46-c5baaa90487b --no-network --winrm-password $OS_PASSWORD -VV --winrm-user 'sandbox.com\boconnor' --bootstrap-protocol winrm --yes --session-timeout 10 --print-after --auth-timeout 10 --user-data ~/userdata_w_creds.txt --winrm-authentication-protocol kerberos
...
Waiting for winrm to host ($ip_address)DEBUG: Looking for key winrm_authentication_protocol and found value kerberos
DEBUG: Looking for key winrm_authentication_protocol and found value kerberos
DEBUG: Endpoint: http://1:5985/wsman # <-- huh?
... 
Waiting for remote response before bootstrap.DEBUG: echo . & echo Response received.
... # many debug messages later
..DEBUG: echo . & echo Response received.
.DEBUG: echo . & echo Response received.
ERROR: No response received from remote node after 9.84 minutes, giving up.
ERROR: Exception: No route to host - connect(2) for "1" port 5985 (1:5985)
FATAL: Check if --bootstrap-protocol and --image-os-type is correct. No route to host - connect(2) for "1" port 5985 (1:5985)
ERROR: Errno::EHOSTUNREACH: Check if --bootstrap-protocol and --image-os-type is correct. No route to host - connect(2) for "1" port 5985 (1:5985)```

I've checked the suggested flags and those are both in place. The problem seems to be that we're connecting to "1". Testing winRM using the IP address of the host, I can connect or even bootstrap without a problem.

knife winrm -m $ip_address -x 'sandbox.com\boconnor' 'dir c:\' --winrm-authentication-protocol kerberos

Does the 1 actually represent the server's hostname/address in this case? I would think using similar techniques seen in knife-windows could resolve the matter.

[jjasghar]

Interesting, well first off, something that makes me unsure of how or even if your setup will work: DEBUG: Looking for key winrm_authentication_protocol and found value kerberos. I know i havent tested knife-openstack with anything then Basic Authentication and it's stated in our README. Needless to say something is figuring out kerberos, so there is some support there but not 100%.

I don't have access to any setup other then Basic, so if you are willing to own this, make a PR and work through it I'd love to merge the support in. Otherwise I don't think I can help you.

It looks like it's coming from knife-cloud also, which adds another layer of complexity.

[jjasghar]

@brandoconnor have you created a work around for this? Is this still an issue? I don't have access other than Basic to attempt to repo this.

[brandonjbjelland]

@jjasghar it's still an issue but I'm squarely working on other things and can get around this through a two step provision or spinning up hosts with userdata that registers the new host to chef server.

[thindiyeh]

I am having the same issue, it seems that it would only pull the first character of the IP address, I tried it with two different openstack environments, and three different new chef dk servers, with all of them I am getting the same results....Please let me know if there is a fix for this issue.

[root@chefwk1 chef-repo]# knife openstack server create -I winbase2012r2v2 -f 3 -S mykey --metadata admin_pass=P@ssword1 --bootstrap-protocol winrm -P P@ssword1 -x Admin -N cheftest1 --winrm-transport ssl -VV --winrm-authentication-protoc
col basic --winrm-ssl-verify-mode verify_none --network-ids bcf79d06-ba5c-48ca-ae20-4678aa1ea495
INFO: Using configuration from /root/chef-repo/.chef/knife.rb
DEBUG: openstack_username admin
DEBUG: openstack_auth_url http://controller:5000/v3/auth/tokens
DEBUG: openstack_tenant 
DEBUG: openstack_endpoint_type publicURL
DEBUG: openstack_insecure 
DEBUG: openstack_region 
DEBUG: Using fog version: 1.37.0
DEBUG: Using fog version: 1.37.0
DEBUG: Create server params - server_def = {:name=>"cheftest1", :image_ref=>"52a00250-19f1-4d6d-a904-bdd81750ac1c", :flavor_ref=>"3", :security_groups=>["default"], :availability_zone=>nil, "os:scheduler_hints"=>nil, :metadata=>{"admin_pass"=>"P@ssword1"}, :key_name=>"mykey", :nics=>[{"net_id"=>"bcf79d06-ba5c-48ca-ae20-4678aa1ea495"}]}

Waiting for server [wait time = 600]....
Instance ID        540f96a5-0096-48db-9bbd-58d83850d537
Name               cheftest1                           
Public IP          192.168.232.127                     
Flavor             3                                   
Image              52a00250-19f1-4d6d-a904-bdd81750ac1c
Keypair            mykey                               
State              ACTIVE                              
Availability Zone  nova                                
DEBUG: Addresses {"public"=>[{"OS-EXT-IPS-MAC:mac_addr"=>"fa:16:3e:14:bd:1e", "version"=>4, "addr"=>"192.168.232.127", "OS-EXT-IPS:type"=>"fixed"}]}
Public IP Address: 192.168.232.127
DEBUG: Floating IP Address requested -1
DEBUG: Addresses {"public"=>[{"OS-EXT-IPS-MAC:mac_addr"=>"fa:16:3e:14:bd:1e", "version"=>4, "addr"=>"192.168.232.127", "OS-EXT-IPS:type"=>"fixed"}]}
DEBUG: Public IP Address actual: 192.168.232.127
DEBUG: Bootstrap Network: public
DEBUG: Bootstrap IP Address: 192.168.232.127
DEBUG: Bootstrapping the server...
Bootstrapping the server by using bootstrap_protocol: winrm and image_os_type: windows

Waiting for winrm to host (192.168.232.127).........................................................DEBUG: Looking for key winrm_authentication_protocol and found value basic
DEBUG: Looking for key winrm_authentication_protocol and found value basic
DEBUG: Looking for key ca_trust_file and found value 
DEBUG: Looking for key winrm_user and found value Admin
DEBUG: Looking for key winrm_authentication_protocol and found value basic
DEBUG: Looking for key winrm_password and found value P@ssword1
DEBUG: Looking for key winrm_port and found value 5986
DEBUG: Looking for key session_timeout and found value 30
DEBUG: Looking for key session_timeout and found value 30
DEBUG: Looking for key winrm_authentication_protocol and found value basic
DEBUG: Looking for key winrm_transport and found value ssl
DEBUG: Looking for key ca_trust_file and found value 
DEBUG: Looking for key ca_trust_file and found value 
DEBUG: Adding 1
DEBUG: WinRM::WinRMWebService options: {:user=>"Admin", :pass=>"P@ssword1", :basic_auth_only=>true, :disable_sspi=>true, :no_ssl_peer_verification=>false, :ca_trust_path=>nil}
DEBUG: Endpoint: https://1:5986/wsman
DEBUG: Transport: ssl
Doing old-style registration with the validation key at /root/chef-repo/.chef/healthstream-validator.pem...
Delete your validation key in order to use your user credentials instead


Waiting for remote response before bootstrap.DEBUG: echo . & echo Response received.
..DEBUG: echo . & echo Response received.
..DEBUG: echo . & echo Response received.
..DEBUG: echo . & echo Response received.
..DEBUG: echo . & echo Response received.
.
.
.
.
ERROR: No response received from remote node after 24.88 minutes, giving up.
ERROR: Exception: Invalid argument - connect(2) for "1" port 5986 (1:5986)
FATAL: Check if --bootstrap-protocol and --image-os-type is correct. Invalid argument - connect(2) for "1" port 5986 (1:5986)
ERROR: Errno::EINVAL: Check if --bootstrap-protocol and --image-os-type is correct. Invalid argument - connect(2) for "1" port 5986 (1:5986)

[NimishaS]

@thindiyeh, @brandoconnor we are able to reproduce this issue. Looking into this.

[jjasghar]

@thindiyeh (i think we talked to each other today!) https://github.com/chef/knife-cloud/blob/master/CHANGELOG.md#v121-2016-02-24 has been released which should resolve this issue. Please reopen if it's not fixed.

Please update your knife-cloud and reopen this if you are still seeing issues.

[brandonjbjelland]

Sorry for the late follow up here. I shifted away from this effort long ago and abandoned it for simpler Linux pastures. Thanks for driving this along @jjasghar, @NimishaS , and the other contributors here.