-
Notifications
You must be signed in to change notification settings - Fork 101
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
vagrant-openstack windows guest #264
Milestone
Comments
Same here. SSH seems to be an implicit requirement. |
Sharpie
added a commit
to Sharpie/vagrant-openstack-provider
that referenced
this issue
Apr 13, 2016
The OpenStack provider's action_up used a custom WaitForServerToBeAccessible action to poll instances via SSH in order to determine when the VM is up and running. One large shortcoming of this custom implementation is that it does not support communicators other than SSH, notably WinRM. This patch replaces the WaitForServerToBeAccessible with the built-in WaitForCommunicator action which has been part of Vagrant since v1.3 and is able to handle multiple communicators. Fixes ggiamarchi#264. Closes ggiamarchi#227.
Sharpie
added a commit
to Sharpie/vagrant-openstack-provider
that referenced
this issue
Apr 13, 2016
The OpenStack provider's action_up used a custom WaitForServerToBeAccessible action to poll instances via SSH in order to determine when the VM is up and running. One large shortcoming of this custom implementation is that it does not support communicators other than SSH, notably WinRM. This patch replaces the WaitForServerToBeAccessible with the built-in WaitForCommunicator action which has been part of Vagrant since v1.3 and is able to handle multiple communicators. Fixes ggiamarchi#264. Closes ggiamarchi#227.
I've opened PR #281 which fixes this by switching to the standard Vagrant WaitForCommunicator middleware which handles WinRM in addition to SSH. |
Sharpie
added a commit
to Sharpie/vagrant-openstack-provider
that referenced
this issue
Jul 25, 2016
The OpenStack provider's action_up used a custom WaitForServerToBeAccessible action to poll instances via SSH in order to determine when the VM is up and running. One large shortcoming of this custom implementation is that it does not support communicators other than SSH, notably WinRM. This patch replaces the WaitForServerToBeAccessible with the built-in WaitForCommunicator action which has been part of Vagrant since v1.3 and is able to handle multiple communicators. Fixes ggiamarchi#264. Closes ggiamarchi#227.
Sharpie
added a commit
to Sharpie/vagrant-openstack-provider
that referenced
this issue
Jul 31, 2016
The OpenStack provider's action_up used a custom WaitForServerToBeAccessible action to poll instances via SSH in order to determine when the VM is up and running. One large shortcoming of this custom implementation is that it does not support communicators other than SSH, notably WinRM. This patch replaces the WaitForServerToBeAccessible with the built-in WaitForCommunicator action which has been part of Vagrant since v1.3 and is able to handle multiple communicators. Fixes ggiamarchi#264. Closes ggiamarchi#227.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is there confirmed way or an example way of spinning up windows with vagrant-openstack provider?
Below is spinning my volume from image, creates an instance with winrm enabled (can telnet) but can't seem to find a way to get winrm confirmation and success. I tried many variations below lists credentials and settings twice but at no point they are picked up by vagrant-openstack plugin. Ssh seems to interfere.
Problem is that if I skip ssh alltogether:
when ssh.username it just keeps expecting ssh
when ssh is disabled, there is no acknowledgement of winrm (therefore no PS1 script can be executed thereafter). premature success.
then tried to fool it by switching standard 22 port to winrm 5985 but
then timeout because winrm is no ssh even though winrm is ready for final success confirmation (and/or ps1 shell script)
The text was updated successfully, but these errors were encountered: