igalia/balena-weston:raspberrypi4-64-c1becf9 not found

[igalia]

igalia/balena-weston:raspberrypi4-64-c1becf9 not found

[psaavedra]

yes, that is the current tagging convention that we are following right now in
https://hub.docker.com/r/igalia/balena-weston/tags:

<machine>-<tag version (commit hash)>
or simply <machine> for the latest version

Ex: raspberrypi3-64-c1becf9

[psaavedra]

Yes apparently this template format only works when you build the image remotely through the balena dashboard. What should be the right way to do define the template for multiple machines?

[rahul-thakoor]

@psaavedra these wpe blocks are very machine specific right?

if they were generic, then we could build multi-arch images and then docker engine would select the right one when the app is deployed.

But considering these images are build for specific targets, i think the current naming template is ok, that is

igalia/balena-weston:<device-name>-<version>

we could also have additional tags for the latest version, so users can simply write

igalia/balena-weston:<device-name>

Yes apparently this template format only works when you build the image remotely through the balena dashboard

can you please elaborate on that?

Are you having issues building and tagging the images when not deploying through balenaCloud dashboard?

I think I ran into the issue since that image does not exist

[rahul-thakoor]

these are the only images for pi4

perhaps you didn't push to dockerhub for commit v1.0.0?

[psaavedra]

You were right. The container just was partially uploaded to the Docker Hub. Now it is uploaded for all the variations: https://hub.docker.com/r/igalia/balena-weston/tags?page=1&name=c1becf9

[psaavedra]

Yes apparently this template format only works when you build the image remotely through the balena dashboard

can you please elaborate on that?

Are you having issues building and tagging the images when not deploying through balenaCloud dashboard?

Apparently, when I build remotely in a Balena Fleet this generates images only for the machine target defined for the fleet but in a fleet you could register several different machines (ex: rpi3, rpi4, ... rpi-64). I was expecting to have a way to build all the required machines needed for my fleet. For example, I would like to create a public fleet to facilitate the evaluation of the WPE browser block.

[rahul-thakoor]

Yes, so as of now, a fleet only supports one architecture and device-type. So when you balena push <fleet>, only one type is built. Let's assume you have a Raspberry Pi 3 fleet, that's armv7hf. Technically, if there are no device-type specific features in your app, you can add all armv7hf devices to that app.

So are there any device-type specific features for wpe? e.g does the raspberry-pi3 target use, different drivers, compared to raspberry-pi4? Pi4 is 64bit OS but it can run apps in 32-bit userland too.

Will building for generic yocto targets(like generic-arm or generic-arm64) work for this use case?

[psaavedra]

Yes, so as of now, a fleet only supports one architecture and device-type. So when you balena push <fleet>, only one type is built. Let's assume you have a Raspberry Pi 3 fleet, that's armv7hf. Technically, if there are no device-type specific features in your app, you can add all armv7hf devices to that app.

Actually the performance of WPE differs depending on the architecture. Ideally we are interesting in provide support for ARMv7 Thumb2 32bits architecture and AARCH64 (64 bits).

So are there any device-type specific features for wpe? e.g does the raspberry-pi3 target use, different drivers, compared to raspberry-pi4? Pi4 is 64bit OS but it can run apps in 32-bit userland too.

For example, and this is just one example, 64bits builts comes with support JIT activated. However JIT is not available in 32bits architectures. The availability of this feature has a big impact in the performance in WebKit WPE. For example, in a RPI4, he MotionMark test can achieve results aroun 12-17 for 64bits userspace binaries but this results becomes more modest when you executes the 32 bits (7-8). The goal of this project is to provide the best user experience as possible so specific tuning looks like a must right now.

Will building for generic yocto targets (like generic-arm or generic-arm64) work for this use case?

For AARCH64 is as kind of yes but not for 32bits. As I said, the performance of the WPE binaries is quite sensitive to the tune flags activated during the configure of the build.

OTOH, for 32-bits, I have to said that generic-arm is not a option. The toll in terms of performance degradation is too big. Tune settings like the CPU model and Thumb2 are really needed.

[rahul-thakoor]

thanks for tha clarification @psaavedra

OTOH, for 32-bits, I have to said that generic-arm is not a option. The toll in terms of performance degradation is too big. Tune settings like the CPU model and Thumb2 are really needed.

I see, so we could have different builds for armv7hf depending on cpu model? Or will we have a single build that caters for different types of armv7 SoC?
I'm asking, so we can then decide how to publish the different base images and make it easier for the end user :)

[psaavedra]

thanks for tha clarification @psaavedra

OTOH, for 32-bits, I have to said that generic-arm is not a option. The toll in terms of performance degradation is too big. Tune settings like the CPU model and Thumb2 are really needed.

I see, so we could have different builds for armv7hf depending on cpu model? Or will we have a single build that caters for different types of armv7 SoC? I'm asking, so we can then decide how to publish the different base images and make it easier for the end user :)

For ARM 32-bits, I'd say different builds using specific CPU tune settings. I dont discard that some builds could fit for different hardware (like the case of the current raspberrypi3 image (32bits)[1] that eventually it is the same than the one in 32 bits for the raspberrypi4 [2] because at the end of the day both are using the same cpu model flags. (But) The same it could not happen for other ARMv7 boards using different instruction sets (Thumb, Thumb2, ... Soft/Hard floating point ...)

[1] https://hub.docker.com/layers/igalia/balena-weston/raspberrypi3-635150f/images/sha256-7b8c437c4ed4c593d9ac9f643f89fc80e2cf2f868288a3399ec2442ef23f3138?context=explore
[2] https://hub.docker.com/layers/igalia/balena-weston/raspberrypi4-635150f/images/sha256-0d7c16920eecd4788bbaca35c0a8a357da2683d1584094892e4a6be47b4a0bb6?context=explore

[rahul-thakoor]

then, the current approach seems good to go.

ie tagging images as igalia/balena-weston:<device-name>-<version>