x/build: add LUCI linux-ppc64le-power10 builder

[pmur]

This will be a builder for GOPPC64=power10 GOARCH=ppc64le GOOS=linux.

The hostname should be linux-ppc64le-power10. The csr is attached: linux-ppc64le-power10.csr.txt

[prattmic]

Right now there is a linux-ppc64le builder backed by the linux-ppc64le-power8 bots.

Am I understanding correctly that this is different hardware and we actually want to rename the linux-ppc64le builder to linux-ppc64le-power8 backed only by linux-ppc64le-power8 bots, and add a new linux-ppc64le-power10 builder backed by the linux-ppc64le-power10 bots?

The way things are configured right now, if we simply add the linux-ppc64le-power10 bots they will get mixed together with the power8 bots in the linux-ppc64le builder because both will report themselves as GOOS=linux, GOARCH=ppc64le.

[prattmic]

If these are same hardware (all POWER 10), then the different would be a matter of setting GOPPC64 env var when building. If they are different hardware, then we'll need to adjust LUCI to be able to determine which version of POWER the current machine is.

[pmur]

The linux/ppc64{,le} builders are backed by physically different hardware as implied by the hostname. The intent is to suss out ISA violations.

@prattmic I think the answer to your question is yes.

[prattmic]

Thanks for the confirmation, that's what I was expecting.

LUCI uses "dimensions" reported by the bot running on the machine to determine which bots are used for which builders. Right now, the linux-ppc64le builder uses os=Linux and cpu=ppc64le as the matching dimensions. There is no preexisting dimension that reports POWER 8 vs 10, so we will need to extend the bot to report on that.

I think the right way to do this is to extend the cpu dimension. The source for this dimension is https://source.chromium.org/chromium/infra/infra/+/main:luci/appengine/swarming/swarming_bot/api/os_utilities.py;l=349. Note that dimensions can have multiple values. So today these machines report ppc64le and ppc64le-64. I think we should also extend them to report something like ppc64le-64-power8 (perhaps leave out the superfluous middle 64).

@pmur could you tell us the best way to determine whether a machine is POWER 8 vs 10 so we can modify the bot? Or if you are willing to navigate the LUCI contribution process and send a CL directly, that would be appreciated.

Given that there are ppc64 ports on Linux, OpenBSD, and AIX, it seems that ideally this detection would be portable across all OSes, though today I believe that only Linux has builders for different ISAs.

[pmur]

I will need it to differentiate between power8/9/10, eventually. Unfortunately, there is no common way to do this. It will take me awhile to get internal approval to send patches to LUCI, I'll start the process. It will be quicker if google can patch it. Here are some notes:

On linux, we match the most recent AT_HWCAP2 ISA support bit set (e.g 3.1 is Power10, 3.00 is Power9, 2.07 is Power8).

On the other platforms, I think it is OK to assume power8 as is done for openbsd/aix today. Though, both of those builders are running power9 hardware.

[pmur]

@prattmic looking at the repo, I think something like the following might do what we want:

--- a/appengine/swarming/swarming_bot/api/platforms/linux.py
+++ b/appengine/swarming/swarming_bot/api/platforms/linux.py
@@ -206,6 +206,8 @@ def get_cpuinfo():
     # MIPS.
     cpu_info['flags'] = values['isa']
     cpu_info['name'] = values['cpu model']
+  elif "POWER" in values.get('cpu',''):
+    cpu_info['name'] = re.search('POWER[0-9]+', values.get('cpu','')).group(0)
   elif values:
     # CPU implementer == 0x41 means ARM.
     if 'Features' in values:

Reading /proc/cpuinfo isn't always perfect, but probably sufficient. Here are the relevant portions from the PPC64 builders (endian doesn't seem to matter):

processor	: 0
cpu		: POWER10 (architected), altivec supported
clock		: 2750.000000MHz
revision	: 2.0 (pvr 0080 0200)

processor	: 0
cpu		: POWER9 (architected), altivec supported
clock		: 2200.000000MHz
revision	: 2.2 (pvr 004e 1202)

processor	: 0
cpu		: POWER8 (architected), altivec supported
clock		: 3425.000000MHz
revision	: 2.1 (pvr 004b 0201)

[pmur]

I think my google CLA from IBM also covers that project too, so I went ahead and opened a CL there .

@prattmic I think this change should populate the cpu field with something like POWER8 which can be translated into passing GOPPC64=power8 to the builder. Though, I am not sure where that should happen.

[pmur]

@prattmic do you know when we will be able to verify the change to detect cpu on ppc will roll out to luci?

[prattmic]

The latest CLs to the swarming bot haven't been released yet, I'll update here when they are.

[pmur]

The change seems to be in. I see ppc64le | ppc64le-64 | ppc64le-64-POWER8 being reported. What needs updated to set GOPPC64?

[prattmic]

I think we want to do two things:

1. In dimensions_of, have the host_type linux-ppc64le-power8 translate to adding dim["cpu"] = "ppc64le-64-POWER8" in order to match the builder to the right hosts. Similar for power10.
2. Separately, in define_builder, add GOPPC64 values for the appropriate builders.

(This is assuming linux-ppc64le builder is renamed to linux-ppc64le-power8. If we want to keep the original name, I believe we can use DEFAULT_HOST_SUFFIX to translate linux-ppc64le to linux-ppc64le-power8.)

cc @mknyszek to check that this sounds reasonable.

[pmur]

This change should also be made for linux-ppc64-* too. Renaming the builders is OK with me, will that also require regenerating the certs too?

[mknyszek]

The naming convention right now would result in interpreting power8 in linux-ppc64le-power8 as a run mod instead of a property of the host. Elsewhere, we delineate that with an underscore after GOOS/GOARCH (so linux-ppc64le_power8). That small note aside, that makes sense to me.

(However, I feel like we also discussed elsewhere that "power8" is a bit weird here in that you can run different ppc64 versions on different hardware, making it closer to a run mod in spirit. I don't remember where we landed on that. The way you've phrased it here, as being a property of the host, makes me think we should use the underscore.)

[pmur]

Ping. I think the linux-ppc64le bot is already named linux-ppc64le-power8. Are we suggesting to change that to linux-ppc64le_power8?

[mknyszek]

I just meant the builder, not the bot.

[pmur]

Hi, is there any progress on the Go team's tooling? I'd like to continue migrating the remaining ppc64 and ppc64le builders.

[dmitshur]

Thanks for the ping @pmur. I have time to help move this forward this week.

I've mailed CL 575856 as the next step here, which should make it possible for you to start connecting bots with the linux-ppc64le-power10 host without them interfering with our LUCI builder definitions for linux-ppc64le (soon to be renamed to linux-ppc64le_power8).

[gopherbot]

Change https://go.dev/cl/575856 mentions this issue: main.star: make power{8,9,10} a part of the host, not runmod

[dmitshur]

Here's the certificate for the bot hostname linux-ppc64le-power10:

linux-ppc64le-power10-1712180608.cert.txt

[gopherbot]

Change https://go.dev/cl/576138 mentions this issue: main.star: add linux-ppc64le_power{9,10} builders

[pmur]

Builder is up and running. Thanks everyone.

[dmitshur]

Thank you very much @pmur. I've mailed you go.dev/cl/576917 to remove its known issue.

[gopherbot]

Change https://go.dev/cl/576917 mentions this issue: main.star: remove known issue for linux-ppc64le_power{9,10} builders