Unable to spin up Windows based image in Azure

[andrejohansson]

First of all, it's a bit unclear if this is a bug or this is a feature request for me, I'm filing it as a bug right now.

I'm trying to spin up a Windows Server 2012 R2 based minion in Azure following these instructions: http://docs.saltstack.com/en/latest/topics/cloud/azure.html

According to the documentation it should be possible to spin up Windows Images http://docs.saltstack.com/en/latest/topics/cloud/windows.html

But trying to spin up one in Azure gives the error:

<Error xmlns="http://schemas.microsoft.com/windowsazure" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><Code>BadRequest</Code><Message>Disktype Windows cannot be used with LinuxProvisioningConfigurationSet</Message></Error>
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/salt/cloud/clouds/msazure.py", line 472, in create

Here is my /etc/salt/cloud.profiles

win2012r2:
  provider: andre-azure-config
  image: 'ad072bd3082149369c449ba5832401ae__Windows-Server-RDSHwO13P-on-Windows-Server-2012-R2-20140421-1748'
  size: ExtraSmall
  location: 'North Europe'
  slot: staging
  media_link: 'http://myblob.blob.core.windows.net/vhds'
  win_installer: /root/Salt-Minion-2014.1.3-1-AMD64-Setup.exe
  win_username: Administrator
  win_password: mysecret

From what I can see the following line is hardcoded to azure.servicemanagement.LinuxConfigurationSet https://github.com/saltstack/salt/blob/develop/salt/cloud/clouds/msazure.py#L437

Shouldn't this be calling azure.servicemanagement.WindowsConfigurationSet depending on image type?

My salt --versions-report gives

           Salt: 2014.1.3
         Python: 2.7.6 (default, Mar 22 2014, 22:59:56)
         Jinja2: 2.7.2
       M2Crypto: 0.21.1
 msgpack-python: 0.3.0
   msgpack-pure: Not Installed
       pycrypto: 2.6.1
         PyYAML: 3.10
          PyZMQ: 14.0.1
            ZMQ: 4.0.4

[techhat]

Part of this one is on us; it should definitely use the azure.servicemanagement.WindowsConfigurationSet for Windows. However, the win_installer, etc. configs require port 445 to be open on the target image, and most providers don't do that by default. Do you know if the Azure image that you're using meets that requirement?

[andrejohansson]

Sorry, I have no idea, I used "list_images" and just picked one of the default azure images. So I'm guessing that the port is not open.

If the win_ configs are not used and the images spin up, is it still possible to configure the minion afterwards or are both needed on spinup?

[techhat]

Once the image is spun up, you can either open up port 445 and use the saltify driver, or you can just run the salt-minion windows installer manually.

Keep in mind that just because that port isn't usually open by default, doesn't mean that Azure doesn't open it. It's probably worth spinning up an image manually and checking.

[andrejohansson]

Hmm, I don't know if that is a good fit for my use case. I was thinking of using Salt to deploy and scale our application. The application consists of different components running on different parts of Azure and AWS.

My idea was to define the applications infrastructure in salt and then get a mechanism for "one button deployment/scaling".

But if it is required to manually work on a deployed instance to get the minion on there the concept fails. Is there other ways to get the minion on the instances?

Of course I could make custom images but it would be preferable if the standard issue images could be used directly. Could salt be pushed out via remote powershell maybe?

Or maybe I'm stretching a bit what salt is made for?

[andrejohansson]

I've started on a fix here but I didn't get all the way, maybe something you can use? https://github.com/andrejohansson/salt/commit/84f61683c53a13bba0ecdd82901ce9f813618b98

My comment was wrong, the instance do spinup but I set it to staging mode. I couldn't RDP to the machine. Running another test with production now to see if RDP is open.

[techhat]

RDP is, to my knowledge, the only port opened by default on a Windows install. That's helpful, because with a desktop you can open up other ports or disable the firewall entirely, but that's still a manual process. I have heard a rumor that RDP can be used to open a port in an automated fashion, but I have been unable to find instructions. It looks like you're headed in that direction; do you know how to do it?

[UtahDave]

To automate opening a port using RDP you have to enable the option to be able to shell out through RDP.

[andrejohansson]

Is there any news on this? Because as I see it, it is not possible to spin up Windows based servers on Azure using salt-cloud today right?

[egilh]

I am seeing the same issue as andrejohansson. Using version 2014.10 I can't spin up Windows VM's in Azure. Like posted above, it seems to ignore win_password and win_username, forcing to set ssh_username and password, which again fails.