Provision Raspberry Pi 4B nodes installed in Colozüri

[aahlenst]

12 Raspberry Pi 4B with 8 GB RAM each and 256 GB SSD have arrived. Installation in rack is currently underway. Steps to do:

• [ ] Decide on build/test/compliance split
• [ ] Decide on bitness/OS split
• [ ] Preconfigure machines (OS, network)
• [ ] Provision machines with Ansible.

11 of the nodes can be allocated freely. I have to set one aside as management node (netboot server).

The CPU on the 4B is dual-mode (32/64 bit) capable. As we're currently short on 32 bit ARM nodes and have more than enough 64 bit capacity, I plan to provision all as 32 bit machines except we want to set aside a few for 64 bit TCK duty @smlambert.

Without 64 bit TCK, I suggest the following split:

• 2x 32 bit build
• 6x 32 bit test
• 3x 32 bit TCK

I plan to install Ubuntu 20.04. The update story for the Raspberry OS (formerly Raspbian) seems murky. Fedora requires an upgrade every 6 months. If anyone has better suggestions, let me know.

[sxa]

I'll repeat here what I said in the Slack channel. I would propose:

• 2 x 32-bit Ubuntu 20.04 for TCK
• 2 x 64-bit Ubuntu 20.04 for TCK
• 2 x 32-bit Ubuntu for build (Current machines are Ubuntu 16.04 but that's going out of support, may not be properly available for the pi and we ideally don't want to regress supported libc prerequisites, so using an Ubuntu 16.04 docker image on a 20.04 host might be the best option)
• Rest of the machines for test - Ideally a split of 32-bit OSs so I'd suggest Ubuntu 20.04 and Raspbery Pi OS as a minimum as the likely "popular" options for Linux/armv7l (assuming security updates for Raspberry PiOS are good). I'd ideally like something like a Fedora too and take the 6-monthly upgrades if it is available as 32-bit (Honeslty, I'd like ot test on more up-to-date OSs than we currently do) but I don't think it is available, in which case I'd probably choose a Ubuntu 20.10 to have one "bleeding-edge" system

[smlambert]

Last I checked for every 1 hr of build, we had around 17hrs of testing. With the addition of TCKs, that ratio could be more like 1:48.

Since we should have 2 machines minimum for build (for redundancy), I agree with https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues/2038#issuecomment-800446932 that allocation seems a reasonable starting point.

[sxa]

(Whispers secretly to @smlambert: I was probably going to make one of the 2 build machines shared with test anyway, particuarly since for arm32 we don't have multiple variants to build in parallel, so unlike most platforms the second build machine is purely for redundancy, not for build capacity)

[aahlenst]

Uhm, I don't love this sharing thing because it subverts isolation of the machines. This is something we should improve, not weaken.

[sxa]

Uhm, I don't love this sharing thing because it subverts isolation of the machines. This is something we should improve, not weaken.

Honestly I'd probably dedicate one for build but have one other as a test macine most of the time but be able to be switched in if required (i.e. if the build box goes down, switch the label on it to change its role).

We've had the discussion on sharing quite a few times in the past. In generally I prefer not to, but particularly for arm32 I don't think we'll hit too much of a capacity issue anyway with the three machines - it hasn't caused us a problem with three systems from you and I that we've had for the last few months

[sxa]

Current status: About 8 of them are online running the default Raspbian OS they were installed with, but the others don't appear to be accessible. Still needs time spent on it to sort out the configuration for the future.