Request a Windows Server 2019 machine to add to set of Windows test machines

[smlambert]

Related to https://github.com/AdoptOpenJDK/openjdk-website/pull/655, would be good to have a Windows Server 2019 in the open set of machines if we state we support it.

[sxa]

@Haroon-Khel Can you provision up a Windows Server 2019 box internally and see if the playbooks run ok on it please?

[Haroon-Khel]

@sxa555, @sej-jackson was kind enough to run the playbook on one of her internal machines, a hursley.ibm one. They ran successfully, though she skipped one of the Java Installs, the jenkins and the ntp_time tasks.

Despite this, I don't think this is an adequate indication of whether the playbook runs smoothly on a Windows Server 2019 machine, as I suspect that her machine has certain configurations which our adopt/external machines wont have. But until I get my MSDN licence approved (to be able to run the playbook against a 2019 machine in fyre), this gives us some indication.

[Haroon-Khel]

Currently running the playbook against a Server 2019 Datacenter machine. Am getting checksum errors for any task involving the download of a package.

I have asked @Willsparker if he could recreate the errors using vagrant boxes

[sxa]

@Haroon-Khel Have you checked the length of the files being downloaded to your machine compared to downloading them elsewere?

Which version of ansible are you using - it may well be that you're getting truncated files if using the latest ansible (There's an issue about it somewhere but I can't find it just now). If you back off to 2.8 or earlier that will resolve it assuming that's the issue you're seeing.

[Haroon-Khel]

Yeah I think it might be an ansible version error. Mine is 2.8.5. I think the current playbooks use a pre 2.8 method of specifying the checksum. I will consider downgrading.

For future reference, do we, as adopt, recommend a certain version of ansible?

[sxa]

No we only specify a minimum. There's a particular bug with 2.9 that has broken the win_url operation universally on Windows

[Willsparker]

I've just checked using a Vagrant VM of Windows Server 2012r2, and the checksums do still work on this case (Using Ansible 2.5.1). Ansible 2.9.3 has been released now so I'll update the infra-vagrant-1 and infra-vagrant-t541 machines to see if either the checksum issue you're experiencing is still there, or if the win_get_url module is still an issue.

[sxa]

@sej-jackson Which version of ansible were you using? I think you backed off to something pre-2.9 after hitting the download issue with win_get_url

[sej-jackson]

The system I'm using is v2.9.2. It turns out that Marcus didn't back it off on this system - the one he did is apparently running ansible v2.2.1.0.

[Haroon-Khel]

Though not yet merged, I was able to run the windows playbook using https://github.com/AdoptOpenJDK/openjdk-infrastructure/pull/1113. This pr simply updates the checksum parameters to use checksum_algorithm, to comply with ansible 2.8 onwards. However I had to omit the cygwin and MSVS_2017 tasks as their install took too long, to the point where ansible's connection timed out.

The OpenSSL : Install OpenSSL-1.1.1d 32-bit task fails with the error:

"msg": "invalid working directory path 'C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\Tools'", 

Am looking into this

Every other task ran fine

[Haroon-Khel]

I am currently running the cygwin and MSVS_2017 tasks separately

[Haroon-Khel]

The cygwin and MSVS_2017 ran successfully. The failing OpenSSL task managed to run without error once I ran it on its own.

To conclude. The playbook runs on the 2019 windows machine

[Haroon-Khel]

@smlambert Can this issue be closed?

[sxa]

I don't think we have a suitable machine at adoptopenjdk yet so I don't think it can be closed, although now we know the playbooks work we can look at acquiring one :-)

[sxa]

Have got two machines currently being set up - 34.244.74.139 and 34.245.29.235. The second of those has a restricted set of things installed (MSCS_2010, VS2010_SP1, Freemarker, Java7, 10, 12, 13, OpenSSL and MSVS_2013) which I think will still allow the testing to work ok assuming that the tests will work ok with only the Visual Studio 2017 compiler installed.

[sxa]

Both set up - if someone (I'm voting @adam-thorpe and/or @M-Davies!) can run a few Grinders including one system test on each of these that would be useful. I've left the ci.role.test label off until we have verified that they are running ok

[sxa]

Special BOGOF offer - two machines now enabled and initial execution of Grinder jobs looks ok, although I haven't got the jenkins agent working properly as a service ... And I've ended up with two jenkins home directories. But in the interests of getting capacity back up with the demise of the godaddy servers, this will do :-)

Just awaiting final verification that the machine setup is ok via Grinder jobs and I'll add ci.role.test

[sxa]

Done. Live.