Add ARM64v8 support to xwiki

[odidev]

This PR has been raised to add support for arm64v8 to xwiki.

I have verified the xwiki build and run on arm64v8.
The support for arm64v8 has been added to postgres based tags as postgres is officially supported over arm64v8 architecture.

I can provide build-run logs as required for confirmation.

Regards,

[tianon]

cc @acotiuga @tmortagne @gdelhumeau @Enygma2002 @vmassol

[vmassol]

@odidev Thanks a lot for this PR. I don't have the ability to verify it myself but the fact that you tested it is good enough for me. I have one question though: you added the arm64v8 architecture only for the postgresql images. Is that because the MySQL ones don't support that architecture or because you haven't tested it with MySQL?

Thanks again

[odidev]

@vmassol
Hi Vincent,
Yes you right, I added support just for postgreSQL based images.
Right now, MYSQL doesn't support arm64v8, and then I didn't want to raise a PR without verifying proper working.

In my view, we can add support for arm64v8 currently and then enhance xwiki for MYSQL later.

Regards,

[vmassol]

@odidev Thanks for the explanation! What would be great is if you could add some comments in the file explaining why we don't have arm64v8 for mysql, maybe with a link to a page/issue explaining that mysql doesn't support arm64v8 yet (if that exists).

Then we can merge this PR, thanks again

[vmassol]

@odidev Found docker-library/mysql#318, maybe you could reference this issue in your comment?

[yosifkit]

MariaDB does support arm64v8 (MariaDB/mariadb-docker#184) and users don't have to run the database on the same machine as xwiki, so I think it would be safe to add it for the images that use MySQL.

@odidev, do you have a moment to test it with MariaDB, an external MySQL/MariaDB, or using the experimental mysql/mysql-server:8.0-aarch64 (docker-library/mysql#318 (comment)) image?

[odidev]

Hi @yosifkit

By using mariadb and mysql-server:8.0-aarch64, I can see build and run success with xwiki
Now should I update my PR with support for all databases or just wait for the official release of MySQL for arm64v8 ?

In my view MySQL-aarch64 is still not official.
So we can provide xwiki for arm64v8 with just postgreSQL for the moment and then enhance it later with MySQL for arm64v8

Regards,

[vmassol]

@odidev sounds good. Could you just update your PR with a comment so that when we next look at it, we understand why the arm64v8 architecture is not set for mysql? thx!

[odidev]

Hi @vmassol
I have updated this PR with enhanced comment message with details regarding MySQL.

[vmassol]

@odidev hmm I don't see it on https://github.com/docker-library/official-images/pull/4723/files, maybe you didn't push? I meant adding a comment in the file :)

[odidev]

@vmassol - Yeah, it was my misunderstanding.
Just updated the commit :)

[vmassol]

@yosifkit All good for me you can apply the PR if you're ok too. Thx

[yosifkit]

LGTM

Diff:

diff --git a/_bashbrew-arches b/_bashbrew-arches
index e86c199..4bf64cd 100644
--- a/_bashbrew-arches
+++ b/_bashbrew-arches
@@ -1,4 +1,6 @@
 xwiki:latest @ amd64
 xwiki:lts @ amd64
 xwiki:lts-postgres @ amd64
+xwiki:lts-postgres @ arm64v8
 xwiki:stable-postgres @ amd64
+xwiki:stable-postgres @ arm64v8

[tianon]

LGTM

Build test of #4723; 3a38ccf; arm64v8 (xwiki):

$ bashbrew build xwiki:9
skipping "xwiki:9" (due to architecture "arm64v8"; only "amd64" supported)

$ test/run.sh xwiki:9
testing xwiki:9
	image does not exist!


$ bashbrew build xwiki:9-postgres-tomcat
Pulling tomcat:8-jre8 (xwiki:9-postgres-tomcat)
Building bashbrew/cache:8059d9ce70b25e6f2c0888022615c29e8a202f573e2c834f6d46631ee0579a84 (xwiki:9-postgres-tomcat)
Tagging xwiki:9-postgres-tomcat
Tagging xwiki:9.11-postgres-tomcat
Tagging xwiki:9.11.7-postgres-tomcat
Tagging xwiki:postgres-tomcat
Tagging xwiki:lts-postgres-tomcat
Tagging xwiki:lts-postgres

$ test/run.sh xwiki:9-postgres-tomcat
testing xwiki:9-postgres-tomcat
	'utc' [1/4]...passed
	'cve-2014--shellshock' [2/4]...passed
	'no-hard-coded-passwords' [3/4]...passed
	'override-cmd' [4/4]...passed


$ bashbrew build xwiki:10
skipping "xwiki:10" (due to architecture "arm64v8"; only "amd64" supported)

$ test/run.sh xwiki:10
testing xwiki:10
	image does not exist!


$ bashbrew build xwiki:10-postgres-tomcat
Building bashbrew/cache:380bf8c2d8ae57132dd9d1becf65f1496bb06369db29bd5825eba6ae28dd0be8 (xwiki:10-postgres-tomcat)
Tagging xwiki:10-postgres-tomcat
Tagging xwiki:10.6-postgres-tomcat
Tagging xwiki:stable-postgres-tomcat
Tagging xwiki:stable-postgres

$ test/run.sh xwiki:10-postgres-tomcat
testing xwiki:10-postgres-tomcat
	'utc' [1/4]...passed
	'cve-2014--shellshock' [2/4]...passed
	'no-hard-coded-passwords' [3/4]...passed
	'override-cmd' [4/4]...passed

The following images failed at least one test:

• xwiki:
  • xwiki:9
  • xwiki:10

[odidev]

It seems xwiki is still not added for arm64v8 in the official build.
I am unable to see any entry for arm64v8 in the manifest for xwiki.

Also, docker pull xwiki is still not working for arm64v8.

[yosifkit]

@odidev, it is there, but it is not on latest since that tag is MySQL based. Try using one of the PostgreSQL tags like lts-postgres

$ manifest-tool inspect xwiki:lts-postgres
Name:   xwiki:lts-postgres (Type: application/vnd.docker.distribution.manifest.list.v2+json)
Digest: sha256:91123e2e4d3e88b9ea58da22e0e2236cf76b07b19050cde62ffc7872441ad1c8
 * Contains 2 manifest references:
1    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
1       Digest: sha256:02489535776fa3dd6e4f8483bb4b7d4eeabafbbc952b6bf8b3ca976a59d1909f
1  Mfst Length: 4304
1     Platform:
1           -      OS: linux
1           - OS Vers: 
1           - OS Feat: []
1           -    Arch: amd64
1           - Variant: 
1           - Feature: 
1     # Layers: 19
         layer 1: digest = sha256:55cbf04beb7001d222c71bfdeae780bda19d5cb37b8dbd65ff0d3e6a0b9b74e6
         layer 2: digest = sha256:1607093a898cc241de8712e4361dcd907898fff35b945adca42db3963f3827b3
         layer 3: digest = sha256:9a8ea045c9261c180a34df19cfc9bb3c3f28f29b279bf964ee801536e8244f2f
         layer 4: digest = sha256:1290813abd9d0a07ce709b4e491f4194f2b854295d93bdc068b7a576756fb515
         layer 5: digest = sha256:8a6b982ad6d7f57b4a8a4052561dc7b0377bd8d4028bce8a93a4d31e60b79329
         layer 6: digest = sha256:abb029e68402beca7edc4627d5034aa72b37c74d8af9badb3284a69f17b91bb6
         layer 7: digest = sha256:d068d0a738e5053cbca5643bc07bc278f76d3769cd69b8afda717c695c210f18
         layer 8: digest = sha256:42ee47bb0c52e5210fb8b964b20a471bc9591949cc7c6c45d14d4679eae2f2ed
         layer 9: digest = sha256:ae9c861aed252f048e32383d4f54fe14a59facff54504b421ee7818543a43bd6
         layer 10: digest = sha256:60bba9d0dc8d1f5a1a7c972a86427b45f4e62736531f7534d2c002aa0a01c0c4
         layer 11: digest = sha256:091c11d70257d1ca60c8094bd2e17ba58bfe579bfb1d561d9a5e202197bb8de3
         layer 12: digest = sha256:869034383fc79000c9525311dc2c6fe6ce2b5700bc18afedb00ce39f96f753e4
         layer 13: digest = sha256:d402c2306e1bf8c608718c583a259c865dbab3caa0afd79ced2fc079b1c1f7ef
         layer 14: digest = sha256:782936ddb6ba0663e357cb66abe01fda29ae91231514602e84af19ebe1b6bf0e
         layer 15: digest = sha256:4baa510e9a823e498bcfcf36e20009342f4c733f7049ecedf19e6be20afe319f
         layer 16: digest = sha256:db88bc7cc88299895f12f1be44f0d5e2f2686120bac03a4fb3511f748402fb4c
         layer 17: digest = sha256:c420bfe2f9fc95fddb3e90a6682c1fafe7bf58c46afcd739b2f50b59bfdb58d4
         layer 18: digest = sha256:8fce0a86170e877d2855b750f622ec4af0b77550ce43be6e5ea6d3d938f395be
         layer 19: digest = sha256:f966bf9419b022ee901fe91e992ed3d98885f309ba43664c83c0075e331f38b5

2    Mfst Type: application/vnd.docker.distribution.manifest.v2+json
2       Digest: sha256:d0387597a62b43acf775a730a377e59e59694c3138c9143c511aea932e41d4e9
2  Mfst Length: 4303
2     Platform:
2           -      OS: linux
2           - OS Vers: 
2           - OS Feat: []
2           -    Arch: arm64
2           - Variant: v8
2           - Feature: 
2     # Layers: 19
         layer 1: digest = sha256:24e48664c69560cde9534aadde23364122f1feb02b5db0ab3776983a4788ea63
         layer 2: digest = sha256:cbcf842c718cc953be45905967fc6a0114f55314ce412b80107e20d8b43fdcdb
         layer 3: digest = sha256:317d79a9c0a5c766d03c1c253fa09f645ed7321dc3a80e0ae33599958677cd1d
         layer 4: digest = sha256:f34353c71abcb0a3423640b466779e00b7da4d2d4ebcdd89f3611d4c936b14ef
         layer 5: digest = sha256:11a58de95103410c7614c07fbfbd2339f5b6657abdb8d847198c246eb1d753e3
         layer 6: digest = sha256:523b8fda53cc2bfd5306eedc221a547f3dd09df4aa2eeb8b0a72da68eace3c68
         layer 7: digest = sha256:cf4fd39dafb9ad45f57c89125992e8197ddf2b218db872801723f2f7f9c0d9e5
         layer 8: digest = sha256:df7e84d92bb0c762009e72f6bcebe6327697bba2477ece3bf08ad63e7b8dce4f
         layer 9: digest = sha256:551345d277a191d95debd27b75bdbdb78648d06685944c72086801e3487f9442
         layer 10: digest = sha256:32bd54ef0d6ed3ddbb887253ddb5b5c19ded33aa90ea991722ec94e042daae24
         layer 11: digest = sha256:3aa8a78965fad6f729ab09ccfa615ea8ac70e7344db699d4d37e063f962884f1
         layer 12: digest = sha256:e796164c542112444c7f9b9d82c983d8fbfd17333a5ae714365928c15d2c7aa8
         layer 13: digest = sha256:05f3219a30e8b203aea7be28cfcd616e6eb32a1f2732b545d50e11edde95f3a1
         layer 14: digest = sha256:8afad7a34c405801567ec69d011caa8642f8c42059eeafedc1d76d8e8fe9985c
         layer 15: digest = sha256:baa2c78eb97df85a44f66400a7020709ce8aaa3790c07c7960b81c94b7778e6e
         layer 16: digest = sha256:6f936b20bfd6589831142311bf322c566fc81dbaf7d35cce33fca22969f60ee8
         layer 17: digest = sha256:9ebf9eb752754ef6eff009f60bcdc63b78a57aef42a137d6494a0b576af5bec6
         layer 18: digest = sha256:c366d37638dd01fdc7f09c2efbe45d5e59e28175607c0e448e3cbb3f3c0ca765
         layer 19: digest = sha256:54530897534541eeba0acea7853827cc10c5a479306530e2e952188b8191d35c

[odidev]

@yosifkit, Yes you are right.

Is there any way to point the latest tag to multiple options depending on architecture?
Something like:

amd64 -->  MYSQL
arm64v8 --> postgres

In this way docker pull xwiki will give mysql based image for amd64 while it will give postgres based image for arm64v8

Regards,

[vmassol]

In this way docker pull xwiki will give mysql based image for amd64 while it will give postgres based image for arm64v8

I'm not sure we would want that since the goal is also to have amd64 for mysql in the future. I prefer to keep mysql be the default TBH. Changing that later on would be a mess IMO.

WDYT?

[odidev]

@vmassol - Yes I also agree with your concern.
Although, I am not an expert in these docker library tags management, but I am just wondering whether it is possible to have multiple options for latest tag, where latest will point to multiple options depending on the architecture.

If it is possible then,
docker pull xwiki will give MySQL based image for amd64 while it give PostgreSQL based image for arm64v8.
In this way, the working of default amd64 will not be disrupted.

Regards,

[yosifkit]

No, we don't have a way to specify using a different tag from each architecture for a main tag like latest.