Description of problem: For Windows machines, a UserDataSecret which contains a PowerShell script for setting up SSH is passed to the ProviderSpec and is written to disk. On Azure, that script is not run automatically on startup (on AWS it is run automatically). Therefore, SSH is never configured on the machine, and it can't be connected to. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create a Machine from a Windows Image Actual results: Windows Machine has no SSH access configured Expected results: Windows Machine has SSH access configured Additional info: https://azure.microsoft.com/en-us/blog/custom-data-and-cloud-init-on-windows-azure/
This bug needs to be fixed for releasing Windows support in the 4.6 timeframe, so I am setting the release to 4.6.
Verified clusterversion: 4.6.0-0.nightly-2020-09-24-211545 machineset yaml: spec: replicas: 1 selector: matchLabels: machine.openshift.io/cluster-api-cluster: sgao-f27xm machine.openshift.io/cluster-api-machineset: win template: metadata: labels: machine.openshift.io/cluster-api-cluster: sgao-f27xm machine.openshift.io/cluster-api-machine-role: worker machine.openshift.io/cluster-api-machine-type: worker machine.openshift.io/cluster-api-machineset: win machine.openshift.io/os-id: Windows spec: metadata: labels: node-role.kubernetes.io/worker: "" providerSpec: value: apiVersion: azureproviderconfig.openshift.io/v1beta1 credentialsSecret: name: azure-cloud-credentials namespace: openshift-machine-api image: offer: WindowsServer publisher: MicrosoftWindowsServer resourceID: "" sku: 2019-Datacenter-with-Containers version: latest kind: AzureMachineProviderSpec location: northcentralus managedIdentity: sgao-f27xm-identity metadata: creationTimestamp: null osDisk: diskSizeGB: 128 managedDisk: storageAccountType: Premium_LRS osType: Windows $ oc get machine NAME PHASE TYPE REGION ZONE AGE sgao-f27xm-master-0 Running Standard_D8s_v3 northcentralus 4h55m sgao-f27xm-master-1 Running Standard_D8s_v3 northcentralus 4h55m sgao-f27xm-master-2 Running Standard_D8s_v3 northcentralus 4h55m sgao-f27xm-worker-northcentralus-5gtvh Running Standard_D2s_v3 northcentralus 4h44m sgao-f27xm-worker-northcentralus-8sgn4 Running Standard_D2s_v3 northcentralus 4h44m sgao-f27xm-worker-northcentralus-mn6zv Running Standard_D2s_v3 northcentralus 4h44m win-xd6f4 Running Standard_D2s_v3 northcentralus 29m $ oc get node NAME STATUS ROLES AGE VERSION sgao-f27xm-master-0 Ready master 4h51m v1.19.0+8a39924 sgao-f27xm-master-1 Ready master 4h51m v1.19.0+8a39924 sgao-f27xm-master-2 Ready master 4h51m v1.19.0+8a39924 sgao-f27xm-worker-northcentralus-5gtvh Ready worker 4h38m v1.19.0+8a39924 sgao-f27xm-worker-northcentralus-8sgn4 Ready worker 4h38m v1.19.0+8a39924 sgao-f27xm-worker-northcentralus-mn6zv Ready worker 4h38m v1.19.0+8a39924 win-xd6f4 Ready worker 24m v1.19.0-rc.2.1023+f5121a6a6a02dd $ oc debug node/sgao-f27xm-master-0 Starting pod/sgao-f27xm-master-0-debug ... To use host binaries, run `chroot /host` Pod IP: 10.0.0.5 If you don't see a command prompt, try pressing enter. sh-4.4# chroot /host sh-4.4# vi openshift-qe.pem sh-4.4# chmod 600 openshift-qe.pem sh-4.4# ssh -i openshift-qe.pem capi.32.9 powershell The authenticity of host '10.0.32.9 (10.0.32.9)' can't be established. ECDSA key fingerprint is SHA256:y9gVw6OJj6Pj396n+svCEQspWtOTqbe6TiYATSEnVc4. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '10.0.32.9' (ECDSA) to the list of known hosts. Windows PowerShell Copyright (C) Microsoft Corporation. All rights reserved. PS C:\Users\capi> exit $ oc logs -f deployment.apps/windows-machine-config-operator -n windows-machine-config-operator 2020-09-25T07:07:06.363Z DEBUG VM win-xd6f4 configuring SSH access to the Windows VM for user {"user": "capi"}
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (OpenShift Container Platform 4.6 GA Images), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:4196