docs: include M1 Chip Workaround

[connorhaugh]

Currently, Devstack and MYSQL interact poorly with newer Apple Machines which use "M1" Chips. An error causes provisioning to fail. A workaround is to specify platform: linux/amd64 under the heading mysql57 in docker-compose.yml and attempting to provision again. Solution found in: https://onexlab-io.medium.com/apple-m1-chip-no-matching-manifest-for-linux-arm64-v8-docker-mysql-5142060a9309 . Update a result of https://docs.google.com/document/d/1XU0z92O_OvVczFavhsxhj-7beWXOc1_4SPPzwwexKho/edit

---

I've completed each of the following or determined they are not applicable:

• Made a plan to communicate any major developer interface changes (or N/A)

[connorhaugh]

Does this kind of documentation of workarounds help, while we work to maybe retire devstack?

[dianakhuang]

I definitely think it's worth updating the docs with what you find! I know there was other previous work to get devstack working with M1s which were less successful (#852) so if this helps fix things at all, that's worth it.

[dianakhuang]

While you're in here, could you also remove this paragraph? We didn't remove it when we should. 😅

[cmltaWt0]

I agree that this update is worth.
The same issue happens for Tutor Devstack too.
Also there is an issue building all frontend apps on M1.

[cmltaWt0]

BTW I'm using image: mariadb:10.4 as a quick workaround for the case.

[cmltaWt0]

Do we need to add another workaround for MFEs?

This is my log from Devstack fresh installation:

ERROR in ./src/generic/assets/edX_certificate.png
Module build failed (from ./node_modules/image-webpack-loader/index.js):
Error
    at afterWriteDispatched (internal/stream_base_commons.js:156:25)
    at writeGeneric (internal/stream_base_commons.js:147:3)
    at Socket._writeGeneric (net.js:787:11)
    at Socket._write (net.js:799:8)
    at doWrite (_stream_writable.js:403:12)
    at writeOrBuffer (_stream_writable.js:387:5)
    at Socket.Writable.write (_stream_writable.js:318:11)
    at Socket.Writable.end (_stream_writable.js:585:10)
    at Socket.end (net.js:591:31)
    at handleInput (/edx/app/frontend-app-learning/node_modules/imagemin-pngquant/node_modules/execa/lib/stream.js:17:17)
 @ ./src/courseware/course/course-exit/CourseCelebration.jsx 18:0-70 88:25-36
 @ ./src/courseware/course/course-exit/CourseExit.jsx 11:0-52 59:29-46
 @ ./src/courseware/course/course-exit/index.js 3:0-38 5:0-47
 @ ./src/index.jsx 15:0-61 78:44-54

Related ticket from tutor-mfe: overhangio/tutor-mfe#31

[connorhaugh]

@cmltaWt0 just to pin down, when you say "MFEs" do you mean frontend-app-learning? I have seen that error myself on M1, but only for that specific MFE. Just trying to pin that down.

[cmltaWt0]

@cmltaWt0 just to pin down, when you say "MFEs" do you mean frontend-app-learning? I have seen that error myself on M1, but only for that specific MFE. Just trying to pin that down.

It happens for all MFEs having optipng as dependency - it simply can’t be build in docker container for linux/arm64. In my case it affects learning, profile, account and maybe gradebook (don’t remember for sure). So everything that works with images.

[dianakhuang]

Hmm, this seems to have a solution/workaround to the optipng issue. Maybe we can get them into frontend-platform to make sure that it builds properly on M1 Macs? https://www.giters.com/nystudio107/craft/issues/71

[johnnagro]

Working on a compatible set of changes here: #920 please check out that branch and let me know your thoughts.