-
Notifications
You must be signed in to change notification settings - Fork 447
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for ARM64 #510
Comments
Hi @throwaway-a! It's not clear to me which image is causing the "pull" command to fail. Can you please try to run:
until you find a culprit? |
It appears to fail on "tutor images pull mysql" |
This issue seems to match the problem reported elsewhere: docker-library/mysql#778
What I do not understand is why other images do not cause the same issue. EDIT: It turns out that mysql is one of the few images that do not provide arm-compatible images.
See the upstream issues: |
does work on both macOS and linux, but then when I go back to running tutor quickstart, it will just complain again about there being no linux/arm64/v8 image. mariadb is a fork of mysql so it should be compatible right? Maybe it's worth trying that out in the future? |
@throwaway-a are you sure myswl works for you?
EDIT: Sorry @throwaway-a I misread your message. I will also specify |
I am not so keen on migrating from MySQL to Mariadb. We are currently running MySQL 5.7.33 in Open edX, and according to my research (including the mariadb docs and this comment) there are compatibility issues between this version and Mariadb. We cannot switch to the mysql-server Docker image because the 5.7 tags do not support arm64. I am not keen either on building the mysql image ourselves from arm64-compatible base images, because we would have to replicate the complex entrypoint mechanism from the base mysql image. Thus, I suggest that we force linux/amd64 emulation on M1. These laptops are not meant for production anyway, so we shouldn't care too much about an eventual performance drop. @Alain1405 @throwaway-a please test the following change. In $(tutor config printroot)/env/local/docker-compose.yml, replace:
by:
(ref: docker-compose spec) Then, run Please report here if this works for you. If yes, I'll open a PR. |
@regisb I tested that today ( However, if you do open a PR to add that, please make it a setting that can be controlled by a variable ( For reference, Guide to running Tutor in dev mode on an M1 MacToday I got Tutor running on my M1 Mac. It was delightfully easy (other than this minor issue). Assuming one wants Tutor installed for dev and the latest Open edX named release available in prod or dev mode, here are the complete instructions, which is what I used:
After I went through all of this, I realized that I should have been using the |
Hey @bradenmacdonald thanks for the comprehensive explanations! Considering the results of the benchmarks you made, I agree with you that the best way to support the arm64 platform is to advise users to switch to MariaDB. They would also have to build the tutor-specific Docker images themselves, thanks to that #543 PR you opened. Would you have time to write a tutorial on how to run Tutor on arm64/Apple M1? If not I can do it myself, based on your testing and reports. |
@regisb Yes, I was thinking of writing a tutorial anyways. I just want to try the nightly mode, and then I can hopefully write a combined tutorial that works for people who want the stable version or nightly. Would you prefer I write it as a forum post or open a PR against the documentation? |
That's great, thanks a lot.
Whichever you are most comfortable with. You have a good understanding of how Tutor works, so I guess you don't necessarily have to go through the forum for validation first. Feel free to add a commit on top of your PR, or open a different one. |
I just tried and this worked great for me on I am trying to create a superuser with
and I think it might be related with the name of the mysql container being different, but I am not sure since LMS seems to run just fine. |
@Alain1405 This is a completely unrelated issue. The mysql container should still have the same name, despite being a different image. I suspect that you are running this "local" command when mysql is actually run in "dev" mode. Since "dev" and "local" containers live in different networks (because the docker-compose project names are different), they cannot communicate with one another. Check which containers are running with |
You are so true @regisb 🤦🏻 . That resolved but I stumbled upon a new issue:
I'm using all default flags to run this dev environment. I guess I could try disabling Course Certificates. It might also be that some migrations did not run correctly. |
FYI, I was able to get both tutor/maple and tutor/maple-mfe up and running this weekend; will follow up with details later today. Required adding a few dependencies for MFE to build properly (and excluding Pact which doesn't yet have an arm64 binary), but overall extremely easy with @bradenmacdonald's how-to. |
OK, instructions in case anyone is trying to replicate a Maple build on M1: mkdir tutor-devstack
cd tutor-devstack
# Set up Python environment (assumes you have Python 3.8 installed; I like using pyenv for this)
python -m venv venv
source venv/bin/activate
pip install --upgrade pip
# Build exim-relay image for ARM64 (used by smtp service)
git clone https://github.com/devture/exim-relay
cd exim-relay
git checkout 4.94.2-r0-4
make build IMAGE_VERSION=4.94.2-r0-4
cd ..
# Clone patched tutor and tutor-mfe branches
git clone -b maple-m1 https://github.com/msegado/tutor
git clone -b maple-m1 https://github.com/msegado/tutor-mfe
# Install tutor and tutor-mfe
pip install -e tutor -e tutor-mfe
# Configure tutor
tutor plugins enable mfe
tutor config save --interactive # answer no to first question
# Switch to MariaDB (see @bradenmacdonald's post)
tutor config save --set DOCKER_IMAGE_MYSQL=mariadb:10.4
# Build images for ARM64
tutor images build openedx
tutor images build permissions
tutor images build mfe
# Initialize and start platform
tutor local init
tutor local start After this, you should have a running Maple (beta) platform, complete with working MFEs. Haven't done too much testing but everything seems to work, including the Learning MFE. The patches themselves are pretty simple. For diff --git a/tutormfe/templates/mfe/build/mfe/Dockerfile b/tutormfe/templates/mfe/build/mfe/Dockerfile
index 726d9ca..b996eea 100644
--- a/tutormfe/templates/mfe/build/mfe/Dockerfile
+++ b/tutormfe/templates/mfe/build/mfe/Dockerfile
@@ -3,7 +3,18 @@ FROM docker.io/node:12-bullseye-slim AS base
RUN apt update \
&& apt install -y git \
# required for cwebp-bin
- gcc git libgl1 libxi6 make
+ gcc git libgl1 libxi6 make \
+ # additionally required for gifsicle, mozjpeg, and optipng
+ autoconf libtool pkg-config zlib1g-dev \
+ # additionally required for node-sass
+ python g++
+
+# Required for building optipng on M1
+ENV CPPFLAGS=-DPNG_ARM_NEON_OPT=0
+
+# Required for avoiding failed frontend-app-learning build due to missing binary on M1
+# (breaks pact tests)
+ENV PACT_SKIP_BINARY_INSTALL=true
RUN mkdir -p /openedx/app /openedx/env
WORKDIR /openedx/app The first environment variable is required to fix the issue described here: imagemin/optipng-bin#117 (comment) Unfortunately the second is a hack that allows MFE to build but will break any Pact tests. I don't see much alternative until there's an ARM binary for Pact though. Relevant issue: pact-foundation/pact-js-core#347 Hope that helps someone, |
@bradenmacdonald @msegado @Alain1405 Your efforts to get Tutor to work on ARM64 have convinced me that we need to support this platform. However, while I appreciate the effort to write a comprehensive tutorial, we need to get to a point where users do not have to apply complex manual patches to their installation to get it to work. At some point we may have to make upstream changes, for instance to MFEs, to make sure that they install properly on ARM64. One option would be to get rid of some packages that do not support ARM64, such as pact. |
I'm also trying to get Tutor working on my Apple M1 machine, and running into this error after making the suggested change to
|
@natea It looks to me like you have used two different versions of MySQL ( |
Agreed :) At least for the non-MFE parts, if you'd be willing to publish arm64v8 images on Docker Hub, no special instructions would be necessary, it would "just work". The instructions mostly cover how to build the docker images from scratch manually. I believe (Edit: Oh, I forgot about MySQL - I guess a workaround would still be needed there unless we add one by default). |
@regisb i suspect that the MySQL running in the Docker container is from a previous version of Tutor, which I don't need anymore. How do I delete that MySQL data folder/volume? |
I think it's acceptable if people just have to perform the following steps:
Rebuilding images is something that many people have to do anyway, because of some theming or because they are running on nightly for instance. I tried building the openedx image with buildx and it failed, for some reason, so we would have to setup a cross-architecture CI to publish ARM64 images -- and this is going to take a while, if ever... EDIT: I just noticed that pyenv gained support for arm64 in v2.2.2: https://github.com/pyenv/pyenv/releases/tag/v2.2.2 this might make it slightly more easy to cross-build images. EDIT2: nope. Build of "openedx" image is failing on apt install:
|
Would it also be something to think about switching from MySQL to MariaDB, or what would it be possible to upgrade to MySQL 8 to better support arm and amd64? As support arm would be great for those running Tutor in AWS, where we could switch to amazon's arm offering. |
@regisb: Not to belabor the obvious, but simple, out-of-the-box support for ARM64 could help build up a user base of edX employees who don't really need all the devstack edge cases and don't want to fight with ARM64+devstack on their shiny new M1 laptops over the coming months. 😛 I mean, don't get me wrong, it's already pretty great with @bradenmacdonald's PR. I didn't mean this to imply that you needed to do a lot of work here–I just wanted to highlight the marketing opportunity. |
Let's close this now that #549 is merged. Please comment here or open a new issue if problems arise on arm64. |
Hi I would like to add something that related to this issue. Everybody is not technical persons , some are users like me. |
Hi @kamkyi, thanks for your constructive comment. It is very helpful. We'll pass it on to our CHO🍎U (Chief Happiness Officer for Apple Users). Next time you feel the need to rant please don't hesitate to post on Twitter, Facebook, or your social networks of choice. Basically anywhere except here on GitHub. |
I recently tried installing on Ubuntu ARM64 (On AWS) and tutor tried to install MySQL 5.7 which is unsupported although open edX already supports MySQL which has a great ARM64 support, the installation failed for many reasons and now I don't have access to the server anymore so I need to do this whole thing from the top. |
Is your feature request related to a problem? Please describe.
When I tried to install tutor on an Apple M1 Mac, I got the following error:
Which I assume just means there's no preconfigured docker containers which run on ARM64.
Describe the solution you'd like
Support for ARM64 macOS native or Linux VM installs.
Describe alternatives you've considered
Only run tutor on x86 systems.
Additional context
Logs:
The text was updated successfully, but these errors were encountered: