Proposal: Unify labelling across adopt github repositories

[sxa]

We've previously had discussions on jenkins machine labelling, but several of the AdoptOpenJDK github repositories use labels for the different OSs and architectures. In openjdk-infrastructure I've tried to standardise these using prefixes for some of the variants such as provider:azure or os:aix or arch:aarch64

openjdk-test has some of the arch: prefixes but not os: and build does not currently use prefixes and has the somewhat ambiguous aarch for aarch64 (presumably to contrast with arm for 32-bit?) as well as separate p-linux, x-linux z-linux (which I'd suggest we replace with separate os:linux arch:ppc64le etc.)

I suggest modifying across all of the relevant repos so that we use consistent naming:

• os: prefixes: linux aix macos windows solaris freebsd (and anything else I've missed!)
• arch: prefixes; x64 (and possible x32/x86/x86-32 if required, could also use x86-64 instead) ppc64 ppc64le arm32 (or aarch32) aarch64 (or arm64 sparc (or sparcv9) s390x (We have a list in https://github.com/AdoptOpenJDK/openjdk-infrastructure/blob/master/ansible/plugins/inventory/adoptopenjdk_yaml.py#L42 as well but that possible needs updating and it would be good to be consistent
• provider: Likely only required for the infrastructure repo but should match these

Where I've listed alternatives in brackets, those are not my personally preferred options)

For awareness and review @M-Davies @andrew-m-leonard @smlambert @aixtools @gdams @karianna

[AdamBrousseau]

Also see discussion in https://github.com/AdoptOpenJDK/openjdk-infrastructure/issues/93

[M-Davies]

arch: prefixes; x64 (and possible x32/x86/x86-32 if required, could also use x86-64 instead) ppc64 ppc64le arm32 (or aarch32) aarch64 (or arm64 sparc (or sparcv9) s390x (We have a list in https://github.com/AdoptOpenJDK/openjdk-infrastructure/blob/master/ansible/plugins/inventory/adoptopenjdk_yaml.py#L42 as well but that possible needs updating and it would be good to be consistent

We have to also keep in mind that these arch values will be used the jenkins job name creation, so they'll be the first thing triagers look at in the mornings.

In this light, I've always found x32 to be more expressive and easier to skim than the others there so my preferred list would be:

• x64 and x32
• ppc64 and ppc64le
• arm and arm32 (do we actually need the version number appended to the end like so 'armv7', 'armv8'?)
• aarch64 and aarch32
• s390x
• sparc and sparcv9
• riscv

...but I understand that a lot of our code uses x86-32 right now so I won't demand this from whoever choses to give this issue a crack

[sxa]

Also see discussion in AdoptOpenJDK/openjdk-infrastructure#93

Thanks - that was the "previousl had discussion" issue that I hadn't yet looked up to reference it :-)

[sxa]

Hmmm you've send you want all of arm arm32 aarch64, aarch32, sparc and sparcv9 - is that what you means? We should attempt to standardise on one for each of those three architectures (Note that riscv which I missed from my list could have riscv64 as an alternative.

Re armv7 armv8 those are effectively synonims for arm32/aarch32 and arm64/aarch64 respectively so should be deprecated in favour of whatever we choose.

[sxa]

We have to also keep in mind that these arch values will be used the jenkins job name creation

Just to be clear, we don't use the values from github issue labels directly in the jobs right? So you're just saying we should try and make them consistent with the jobs for convenience (a good goal obviously)?

One area where we do have a problem is with arm in particular, since the test suites etc. use different namings (a known issue that Shelley and I have discussed before) - the build jobs use arm for arm32, test jobs are named with aarch32 so we already have an inconsistency.

[AdamBrousseau]

While I would directly benefit from the build scripts using the same labels as test and having a standard set across the project, I also think that having all the labels be configurable by third parties without hack and slash would be beneficial.

[sxa]

@AdamBrousseau Devils advocate question: What would be the reasons for wanting to diverge? Compatibility with someone's own existing labels or something else?

[AdamBrousseau]

If another third party already had their own label schema I think it would be beneficial to them if our scripts were configurable.

[M-Davies]

Hmmm you've send you want all of arm arm32 aarch64, aarch32, sparc and sparcv9 - is that what you means? We should attempt to standardise on one for each of those three architectures (Note that riscv which I missed from my list could have riscv64 as an alternative.

A standard for each would be ok for github labels but not for jenkins names (in my opinion) as that would make identifying jobs more difficult.

Re armv7 armv8 those are effectively synonims for arm32/aarch32 and arm64/aarch64 respectively so should be deprecated in favour of whatever we choose.

In that case I choose arm 😊

Just to be clear, we don't use the values from github issue labels directly in the jobs right? So you're just saying we should try and make them consistent with the jobs for convenience (a good goal obviously)?

No we don't use the github issue labels but we do use similar ones (ideally the github issue labels and jenkins job labels should be the same). What I'm referring to is how we construct the job names: https://github.com/AdoptOpenJDK/openjdk-build/blob/b35e817efaa66635e9c21ec197476a8f22ceca6b/pipelines/build/common/config_regeneration.groovy#L532

[sxa]

In that case I choose arm

Just to throw a(nother) spanner in the works, I would probably go for aarch64 since that's what uname -m returns on those systems (Althouh xLinux gives x86_64...) On most of the arm32 system it gives armv7l so normally I'd choose that, but I suspect most people wouldn't find that as clear ...

[aixtools]

Was curious - what would uname -m return on AIX. Neither ppc, nor ppc64. Nope - some number - perhaps related to the processor model.

Still curious: where did ppc and ppc64 actually come from? Was that from back when AIX was ported to the PS3 - that was built on the POWER4 chip? And also linux ported to the PS3 - and likely the imac models built on the POWER4 (or was it POWER5 - for both).

I guess everyone knows what it means (ppc64) - but I doubt that is the abbreviation used to document the processor ABI.

At least power and ppc64 are both 5 characters. :)

[sxa]

Linux has always used ppc64 or ppc64le so it makes sense to be consistent in the architecture name (I /think/ it was ppc32 on a 32-bit Linux on POWER.