Open sxa opened 1 year ago
All windows 2012 machines ( build & test ) now marked offline in jenkins.
All Windows TCK machines except one are Windows 11 as per https://ci.eclipse.org/temurin-compliance/computer/
Currently Running 32 bit tests on Win2022, with WSL disabled
Test Passes: https://ci.adoptium.net/job/Grinder/8152/ & https://ci.adoptium.net/job/Grinder/8137/ & https://ci.adoptium.net/job/Grinder/8157/console & https://ci.adoptium.net/job/Grinder/8158/console
test-azure-win2022-x64-1 has been commisioned following successful testing.
test-azure-win2022-x64-2 has been created and is in jenkins : https://ci.adoptium.net/computer/test%2Dazure%2Dwin2022%2Dx64%2D2/
Testing of the new node in progress...
Success - JDK11 - x64 - System - Sanity - https://ci.adoptium.net/job/Grinder/8183/
Success - JDK17 - x64 - Openjdk - Sanity - https://ci.adoptium.net/job/Grinder/8188/
Success - JDK17 - x86 - Openjdk - Sanity - https://ci.adoptium.net/job/Grinder/8191/
Success - JDK17 - x86 - System - Sanity - https://ci.adoptium.net/job/Grinder/8201/
Success - JDK8 - x64 - System - Sanity - https://ci.adoptium.net/view/Test_grinder/job/Grinder/8202/
Success - JDK8 - x86 - System - Sanity - https://ci.adoptium.net/job/Grinder/8205/
Success - JDK21 - x64 - Openjdk - Sanity - https://ci.adoptium.net/job/Grinder/8207/
Unstable/OK - JDK17 - x64 - Openjdk - Extended - https://ci.adoptium.net/job/Grinder/8210/
Success - JDK17 - x64 - Perf - Sanity - https://ci.adoptium.net/job/Grinder/8214/console
Success - JDK11 - x86 - Perf - Sanity - https://ci.adoptium.net/job/Grinder/8215/
test-azure-win2022-x64-2 has been commisioned following successful testing.
Powered off:
test-azure-win2012r2-x64-1 & test-azure-win2012r2-x64-3
@AdamBrousseau We have four windows server 2012r2 machines defined int eh IBM Cloud - am I right in saying that we can't update / reprovision as 2022 systems ourselves so you would have to manage that for us?
I right in saying that we can't update / reprovision as 2022 systems ourselves so you would have to manage that for us?
Correct, I can delete the old ones and provision the new ones for you (not necessarily in that order). Possibly based on a snapshot of an existing one, if that is of interest. It is on my radar as I have to do the ones for the OpenJ9 project as well. I just don't know when that will be as nobody is pushing hard on me for it yet.
Correct, I can delete the old ones and provision the new ones for you (not necessarily in that order). Possibly based on a snapshot of an existing one, if that is of interest. It is on my radar as I have to do the ones for the OpenJ9 project as well. I just don't know when that will be as nobody is pushing hard on me for it yet.
From my perspective we've now shut off all of the win2012 ones from active service so it can be switched over any time. Since this means we're down to only one provider for Windows systems at the moment (Azure) it would be good to get them replaced and verified before the next quarterly release in January. I don't think we have a suitable system to clone at the moment, but it's probably just as easy to give us clean ones and let us fire the Ansible AWX server at them. I'll let @steelhead31 object to that if he wishes ;-)
Sounds like a plan to me.. :)
The IP address 20.108.178.21
(consistent with https://github.com/adoptium/infrastructure/blob/b728c86a1b2fe798c29cae85f7b23e50ff9686fa/ansible/inventory.yml#L45) is repeatedly (every ten seconds) trying to access it's slave-agent.jnlp in jenkins and receiving a 404. We should stop this or (most likely) fully decommission the machine now.
I missed the last few comments. Is my understanding correct that I can shutdown all your windows build and test systems that are running win2012? @sxa
I'm 99% certain that'll be fine but I suggest we hold off to next week when @steelhead31 is back if that's ok but I believe the intention was to replace them all with something else (potentially a mix of Win2022 and RHEL? Can't recall where we discussed that)
Likely discussed over slack but I thought the plan was to do 1-1 replacement with win2022's. I'm open to discussion. I will hold off until next week.
Friendly bump @steelhead31
@AdamBrousseau , yes please, lets shutdown the 2012 machines ( a total of 4 I believe )
Build : win2012r2-x64-1: {ip: 169.48.4.138} win2012r2-x64-2: {ip: 169.48.4.142} Test : win2012r2-x64-1: {ip: 169.48.4.131} win2012r2-x64-2: {ip: 169.48.4.139}
And if @sxa agrees
I think replacing them with a mix 2 x Win-2022 ( 1 x Build, 1 x Test ) and 2 x RHEL ( 1 x Build & 1 x Test ) would be ideal.
I think that's reasonable (and I guess this explains why Nagios is showing formals against the machines!) Will be interesting to see the timings for Windows systems coming out of my dry ribs tonight for all for releases and 32+64 bit.
For RHEL we should have at least one RHEL9 now I think and the 8 or 9. Will be good to have more systems using podman by default (although the test jobs may require some updates - there's an aqa-tests issue about that)
On Tue, 9 Apr 2024, 21:01 Scott Fryer, @.***> wrote:
@AdamBrousseau https://github.com/AdamBrousseau , yes please, lets shutdown the 2012 machines ( a total of 4 I believe )
Build : win2012r2-x64-1: {ip: 169.48.4.138} win2012r2-x64-2: {ip: 169.48.4.142} Test : win2012r2-x64-1: {ip: 169.48.4.131} win2012r2-x64-2: {ip: 169.48.4.139}
And if @sxa https://github.com/sxa agrees
I think replacing them with a mix 2 x Win-2022 ( 1 x Build, 1 x Test ) and 2 x RHEL ( 1 x Build & 1 x Test ) would be ideal.
— Reply to this email directly, view it on GitHub https://github.com/adoptium/infrastructure/issues/3238#issuecomment-2045959060, or unsubscribe https://github.com/notifications/unsubscribe-auth/APDJLOERUW7FDGQUEB3N52DY4RCLLAVCNFSM6AAAAAA62YGMSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBVHE2TSMBWGA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Spotted today: The build-azure-win2012-x64-2 machine (as opposed to 2022) is still live and should be decommissioned and removed from the inventory. Also we have some cases where the machine's hostname does not match the name in the inventory/jenkins (May not be easy to change, but just worth being aware of)
Noting also that the win2022 build machines still have the ci.role.test label which we should look at removing to ensure the build machines are dedicated as far as possible (I've just had a build fail to be scheduled because of it) ... Although looking at that list we do seem horribly low on Windows test systems just now ...
Both windows 2016 and windows 2019 are out of support ( or more accurately are in extended support ), do we want to decomission the 2 remaining test machines on this O/S ?
I've stopped (2016 - 172.172.147.29 ) and (2019 - 13.92.177.186 ) both test machines in the public inventory.
However there are 2 other windows machines... ( 2016 - 40.121.207.47 , 2019 - 13.68.197.156 ) still running, that arent in either inventory too.. anybody know what these are for ?
These 2 windows machines have now been shutdown ( 2016 - 40.121.207.47 , 2019 - 13.68.197.156 ) to potentially identify any issues.
Our Windows builds are now all running on Windows Server 2022 systems. Now that 2012 as reached the end of extended support we should decommission those and, if required, replace with later versions.
We should also aim to replace the one Server 2016 machine that we have with a Server 2019 system.
It may make sense to try replacing some of the old server 2012 boxes with Windows 11 systems to cover testing on there too, but that should be evaluated to ensure that the playbooks run on that platform and we dont' get any unexpected issues.
So a phased approach to the machine we no longer want: