fuseml-installer lacking arm64 support

[bwgartner]

Following QuickStart

curl -sfL https://fuseml.github.io/in/installer.ps1 | sh -

only provides (so is there another option/variant/argument) ...

file /usr/local/bin/fuseml-installer
/usr/local/bin/fuseml-installer: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, stripped

When will arm64 be an option for the installer (and then for all the other layers of components)?

[stefannica]

Thank you for reporting this.

We do build and release arm64 binaries for the installer (as seen here: https://github.com/fuseml/fuseml/releases/tag/v0.1.1) and for the CLI (as seen here: https://github.com/fuseml/fuseml-core/releases/tag/v0.1.0), but you're right in pointing out that the PS1 script is oblivious to the architecture.

The installer.ps1 script could use some small adjustments to detect the architecture it's running on and automatically choose the correct binary for the installer.

The FuseML installer is also downloading the CLI binary with the correct architecture, as shown here: https://github.com/fuseml/fuseml/blob/main/paas/install_cli.go#L25-L43

As a workaround, one could manually download and use the installer built for the correct arch.

[stefannica]

When will arm64 be an option for the installer (and then for all the other layers of components)?

@bwgartner this should be possible with some minor fixes made to the PS1 script.

Building container images for arm64 is a different story, especially considering that FuseML is installing some components from 3rd party sources that may or may not include this support. Is that what you meant by "layers of other components" ?

[bwgartner]

Thank you for reporting this.

We do build and release arm64 binaries for the installer (as seen here: https://github.com/fuseml/fuseml/releases/tag/v0.1.1) and for the CLI (as seen here: https://github.com/fuseml/fuseml-core/releases/tag/v0.1.0), but you're right in pointing out that the PS1 script is oblivious to the architecture.

The installer.ps1 script could use some small adjustments to detect the architecture it's running on and automatically choose the correct binary for the installer.

The FuseML installer is also downloading the CLI binary with the correct architecture, as shown here: https://github.com/fuseml/fuseml/blob/main/paas/install_cli.go#L25-L43

As a workaround, one could manually download and use the installer built for the correct arch.

Yes, thanks for this pointer/reminder ...

file bin/fuseml-installer
bin/fuseml-installer: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped

So that aspect has a viable workaround for now

[bwgartner]

When will arm64 be an option for the installer (and then for all the other layers of components)?

@bwgartner this should be possible with some minor fixes made to the PS1 script.

Building container images for arm64 is a different story, especially considering that FuseML is installing some components from 3rd party sources that may or may not include this support. Is that what you meant by "layers of other components" ?

Yes, if I am targeting a deployment on an ARM/K*s nodes, then that is the next hurdle (for this K3s example, did leave Traefik in place, since the installer release cites "Handle Traefik ingress for the fuseml-core service")

fuseml-installer install

🚢 FuseML installing...

Configuration...
🧭 system_domain:

⚠️ Traefik Ingress already installed, not installing Istio
.
✔️ Created system_domain: 192.168.27.26.omg.howdoi.website

🚢 Deploying Quarks........................................................................................................................................................................................

which never completes ( Crashloopback mode )

[stefannica]

Re-opening to track adding ARM support for container images

[stefannica]

@bwgartner The FuseML 0.2.1 patch release is available now and includes ARM64 support for the installer, as well as for all associated container images (fuseml-core and those used in the workflow). However, I have not had the chance to test it yet, and there may be some 3rd party tools or even other builtin components that do not feature ARM64 container images.

[bwgartner]

@bwgartner The FuseML 0.2.1 patch release is available now and includes ARM64 support for the installer, as well as for all associated container images (fuseml-core and those used in the workflow). However, I have not had the chance to test it yet, and there may be some 3rd party tools or even other builtin components that do not feature ARM64 container images.

FYI, just ran the Quickstart d'load

curl -sfL https://raw.githubusercontent.com/fuseml/fuseml/main/install.sh | sh -

and still got older fuseml-installer version v0.1.1, like we have talked about in Slack (yet did at least get the Arm64 version - /usr/local/bin/fuseml-installer: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped)

Then doing the install hung at Quarks steps, since that container images seems to be non-Arm64

[bwgartner]

@bwgartner The FuseML 0.2.1 patch release is available now and includes ARM64 support for the installer, as well as for all associated container images (fuseml-core and those used in the workflow). However, I have not had the chance to test it yet, and there may be some 3rd party tools or even other builtin components that do not feature ARM64 container images.

FYI, just ran the Quickstart d'load

curl -sfL https://raw.githubusercontent.com/fuseml/fuseml/main/install.sh | sh -

and still got older fuseml-installer version v0.1.1, like we have talked about in Slack (yet did at least get the Arm64 version - /usr/local/bin/fuseml-installer: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped)

Then doing the install hung at Quarks steps, since that container images seems to be non-Arm64

And just trying again later ...

got fuseml-installer version v0.2.1

?? FuseML installing...

Configuration...
?? system_domain:
?? extension_repository: https://raw.githubusercontent.com/fuseml/extensions/release-0.2/installer/

?? Traefik Ingress already installed, not installing Istio
.
?? Created system_domain: 192.168.27.27.nip.io

?? Deploying Workloads.....
?? Workloads deployed

?? Deploying Gitea........

.error installing FuseML: failed waiting Gitea memcached deployment to come up: Failed waiting for gitea-memcached-7b44bc5f74-26rf2: timed out waiting for the condition
Pod Events:
Successfully assigned gitea/gitea-memcached-7b44bc5f74-26rf2 to node7
Pulling image "docker.io/bitnami/memcached:1.6.9-debian-10-r114"
Successfully pulled image "docker.io/bitnami/memcached:1.6.9-debian-10-r114" in 5.654490489s
Container image "docker.io/bitnami/memcached:1.6.9-debian-10-r114" already present on machine
Created container memcached
Started container memcached
Back-off restarting failed container

with both app-ingress and gitea-memcached possibly hitting the non-Arm64 obstacle (crashloopback iterations)

Which seems to be very common when using bitnami charts that are so x86_64 centric mostly