Two new Windows machines at Azure

[sxa]

I need to request a new machine:

• New machine operating system (e.g. linux/windows/macos/solaris/aix): Windows (2016 and 2019)
• New machine architecture (e.g. x64/aarch32/arm32/ppc64/ppc64le/sparc): x64
• Provider (leave blank if it does not matter): Azure
• Desired usage: Test
• Any unusual specification/setup required: No
• How many of them are required: 2 (one of each OS)

Please explain what this machine is needed for: Replacement of Windows 2016 tets machine at GoDaddy (already decomissioned) and Windows 2019 at AWS (To be decomissioned which this one is up). It is likely that we will decomission one of the three Win2012 test machines at Azure once these two are active.

New machines are at 52.149.211.210 and 20.185.182.137 (2016 and 2019 respectively). Credentials as per the first win2012 test machine on Azure for whoever picks this up to install the playbooks on it :-)

[karianna]

Whoever picks this up LMK if you need access to the Azure portal.

[Willsparker]

I'll set them up :-) I don't think I'll need access to the Azure portal, except for maybe restarting machines, but I should be able to do that via my RDP client.

[Willsparker]

I assume this issue is referring to the same machine requirement at #1884 ? So I can close that issue?

[Willsparker]

Hmm, for the both machines, I can connect via RDP, but I'm getting timeout issues with Ansible, despite increasing the timeout to 60 seconds. (up from 30). I was running the following:

ansible-playbook --limit "test-azure-win2019-x64-1" playbooks/AdoptOpenJDK_Windows_Playbook/main.yml

Having put the password in playbooks/AdoptOpenJDK_Windows_Playbook/group_vars/adoptopenjdk_variables.yml. I have also run all of the ConfigureRemotingForAnsible.ps1 commands for both machines.

[karianna]

Can you manually RDP login?

[Willsparker]

Yeah, I had to to run the ConfigureRemotingForAnsible scripts :-) So it's not the password or IP

[karianna]

Did we move the AWX server since last time? I wonder if it's an IP address/port/Firewall issue.

[sxa]

I assume this issue is referring to the same machine requirement at #1884 ? So I can close that issue?

No this has nothing to do with aarch64

[sxa]

Did we move the AWX server since last time? I wonder if it's an IP address/port/Firewall issue.

I don't believe Will is using AWX (it's not fully set up for Windows yet) so will be running standalone from his laptop

[sxa]

To be clear, is it failing to even connect via WinRM? If so that might be indicative of a firewall or similar blocking the port somewhere along the line

[Willsparker]

I believe so - it's a timeout, it's not permission denied or anything.

fatal: [test-azure-win2016-x64-1]: UNREACHABLE! => {"changed": false, "msg": "credssp: HTTPSConnectionPool(host='52.149.211.210', port=5986): Max retries exceeded with url: /wsman (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x7f3b18d96990>, 'Connection to 52.149.211.210 timed out. (connect timeout=60)'))", "unreachable": true}

It may be a closed port?

[karianna]

Seems likely - do you have access to the Azure portal to see?

[sxa]

Seems likely - do you have access to the Azure portal to see?

I created them with the same groups as the other machiens I believe (We could really do with infra docs for each provider particularly when things are non-obvious)

[sxa]

OK it seems to work when I connect to either 127.0.0.1 or the machines private IP address, which does suggest it's being blocked external to the machine.

[sxa]

Inbound port rule now added fo rthe Win2016 machine so it should work now.

[sxa]

... and the Win2019 machine

[Haroon-Khel]

ref #1818
@Willsparker Is cygwin already installed on the machine? Since these are fresh machines, Im interested in knowing if cmake comes with the cygwin installation in cygwin64\bin, or whether ansible will install it in Program Files\CMake

[Willsparker]

That works now, thanks @sxa

@Willsparker Is cygwin already installed on the machine? Since these are fresh machines, Im interested in knowing if cmake comes with the cygwin installation in cygwin64\bin, or whether ansible will install it in Program Files\CMake

@Haroon-Khel I'll let you know when it's installed, it's running now :-)

[Willsparker]

Just thought I'd mention it here: The MSVS_2013 role is acting a bit weird. It will download the installer and then run it, and report that it succeeded, but then it will fail at this task:
https://github.com/AdoptOpenJDK/openjdk-infrastructure/blob/9d986a531d2262fc2f9cffd4b369952dd8c4d186/ansible/playbooks/AdoptOpenJDK_Windows_Playbook/roles/MSVS_2013/tasks/main.yml#L26

When manually checking, the Microsoft Visual Studio 12.0 dir isn't in Program Files (x86) - however when rerunning the playbook, the stat check for that directory says it's there, so it doesn't attempt to re-run the installation. Running the installation manually works fine.

[sxa]

Something's not quite right on there. Ref: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-windows-x64-hotspot/944/console

11:45:49  Done (129 CA certs processed, 20 skipped).
11:45:50  Processing certificate with alias: subject=C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
11:45:50  ./mk-cacerts.sh: line 79: C:openjdkjdk-8/bin/keytool: No such file or directory
11:45:50  

[Willsparker]

Ah, that's on the 2016 one, which is in the process of having it's PB run on it. Manually installing MSVS_2013 on it now. 2019 has had it's full pb run (but I haven't setup the Jenkins user yet)

[sxa]

Wasn't expecting you to still be online ;-) OK I'll let you complete it (As is now obvious I put the agent on the 2016 box)

[sxa]

FYI That job above (JDK8/HotSpot) is one that will use VS2013 so will be a good test of whether the install is working.

[Willsparker]

2016 has had it's PB run too! Again, had to manually install MSVS_2013

[sxa]

Thanks - queued up another build at https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk8u/job/jdk8u-windows-x64-hotspot/946

FYI @andrew-m-leonard if JDK8/win/hotspot shows in failing builds tomorrow it's because of this new test run, not the nightly

[sxa]

#946 still didn't work - resolved in #947 by setting JDK7_BOOT_DIR in the machine definition to /cygdrive/c/openjdk/jdk-7. Running a JDK11 job at https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-windows-x64-hotspot/915 too

[Willsparker]

I've rerun the JDK11 job, as I think you forgot to fill the NODE_LABEL parameter. https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-windows-x64-hotspot/917/console

[sxa]

NODE_LABEL has a tendancy to disappear when you submit a job (reported at adoptium/ci-jenkins-pipelines#54 (comment)), so I cleaim 😇

[Willsparker]

That's an interesting spelling ...
I saw there was another config issue on https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-windows-x64-hotspot/917/console , thanks for restarting it at https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-windows-x64-hotspot/918/console 😁

[sxa]

Yep I added in a JDK10_BOOT_DIR definition onto the machine. Need to get that autodetected properly as https://github.com/AdoptOpenJDK/openjdk-build/pull/2167/files has a "statement does not equal the printed message" problem

Fixed in adoptium/temurin-build#2482 - once that is merged I can retest with the JDKnn_BOOT_DIR variables removed again

[Willsparker]

918 passed! 👍

[Willsparker]

@sxa What's left in terms of testing the machines? :-)

[sxa]

@sxa What's left in terms of testing the machines? :-)

From your earlier comment:

(but I haven't setup the Jenkins user yet)

So no testing has yet been done on the 2019 machine that I'm aware of. (Also we have #1963 (comment) that needs to be resolved one way or another on the 2016 machine)

[Willsparker]

Ah, my mistake, I thought you did that - I'll do it now

[Willsparker]

The machine's connected 👍 The test-azure-win2019-x64-1 node definition was already there; I'm assuming the labels on it are correct ...

[sxa]

Testing J9 sanity.openjdk at https://ci.adoptopenjdk.net/job/Grinder/7287 on the win2019 machine as a final check although this system suite Grinder has already ran through ok on it

[sxa]

latest Grinder has cleared the build phase and onto testing without problems so I think it's safe. Added ci.role.test and closing this issue. The Win2016 machine has been suffering due to its low amount of memory but that will be dealt with under the separate issue related to that mentioned a few comments earlier.