Skip to content
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

Arm64 support #372

Merged
merged 11 commits into from
May 26, 2023
Merged

Arm64 support #372

merged 11 commits into from
May 26, 2023

Conversation

unkcpz
Copy link
Member

@unkcpz unkcpz commented Apr 23, 2023

  • can only run specific stack build by: doit build --target base --target full-stack
  • Test using self-hosted arm64 runner. Hosted in AWS.
  • mamba-bash-completion package for arm arch

@unkcpz unkcpz marked this pull request as draft April 23, 2023 03:11
@unkcpz unkcpz force-pushed the arm64 branch 11 times, most recently from ca46d54 to 23138b7 Compare April 23, 2023 20:21
.github/workflows/ci.yml Outdated Show resolved Hide resolved
.github/workflows/ci.yml Outdated Show resolved Hide resolved
@unkcpz unkcpz force-pushed the arm64 branch 16 times, most recently from c7d6c02 to a72ac82 Compare April 23, 2023 23:46
Copy link
Contributor

@danielhollas danielhollas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@unkcpz thanks for all your thankless work on this! I've tested it on a M2 Mac machine and it works great.

I mostly just have some clarifying questions, nothing big. I would only suggest we wait till the mamba-bash-completion package becomes available, which should hopefully not be long.

Just as a side note, I found out that I won't be able to run my app on Arm. My app relies on ORCA for ab initio calculations. While ORCA team provides binaries for Mac Arm64, what we actually need here are Linux/arm64 binaries so that they can run inside our Ubuntu container. I didn't quite realized this before. It is a bit unfortunate, I'll see if the ORCA folks would be willing to release a new binary (though our use case seems to be quite niche).

.github/workflows/ci.yml Outdated Show resolved Hide resolved
environment.yml Show resolved Hide resolved
stack/base/Dockerfile Outdated Show resolved Hide resolved
@@ -16,7 +16,7 @@ def is_responsive(url):
return False


@pytest.fixture(scope="session", params=["lab", "base-with-services"])
@pytest.fixture(scope="session", params=["lab", "base-with-services", "full-stack"])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you add the full-stack variant here? What does this bring in terms of testing?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you look at stack/full-stack/Dockerfile you'll find I have re-install erlang even though it is already installed in the base-with-services. The reason is that we use the multiple stage and packages installed in the preliminary stage will not transfer to the final image. This test is will fail if erlang not installed explicitly in full-stack.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, fair enough. I guess my question then is whether there is enough reason to test the "lab" image separately, or whether just testing base-with-services and full-stack is enough (which would also allow us to get rid of bunch of extra skipping logic in some tests. But that can be left for another PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whether just testing base-with-services and full-stack is enough

I am second on this. I didn't see the point to test lab and full-stack. Can you open an issue and assign it to me and you? Should be a quick fix I assume.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to remove the test of base-with-services in #385. The lab is worth testing because we want to be sure strating with docker-compose is working.

tests/test_aiidalab.py Show resolved Hide resolved
@unkcpz unkcpz force-pushed the arm64 branch 2 times, most recently from d7794a1 to 7d345de Compare May 16, 2023 23:15
@unkcpz unkcpz added this to the 2023.1012 milestone May 17, 2023
@danielhollas
Copy link
Contributor

Hey @unkcpz are there any remaining blockers here in terms of all dependencies? Is the QeApp actually running on this Arm image? If yes, maybe @mbercx and @cpignedoli can do final round of testing and we're good to go?

@unkcpz
Copy link
Member Author

unkcpz commented May 24, 2023

Is the QeApp actually running on this Arm image?

Is not, but nothing can be done here. What I need to do is update the qe installed from conda-forge to 7.2 which starts to have arm64 supported.

If yes, maybe @mbercx and @cpignedoli can do final round of testing and we're good to go?

Maybe @cpignedoli can test on Empa apps? I have apple M1 laptop as well so I can give it a test for QeApp. I plan to release a new version with the "daemon stop" fix. Let's see how fast I can make a QE update for the app.

@unkcpz
Copy link
Member Author

unkcpz commented May 24, 2023

Running a test on my M1 chip laptop with the QE from conda-forge, and all is good aiidalab/aiidalab-qe#404 🎊

@cpignedoli
Copy link
Member

@unkcpz I will test everything hopefully by tonight.

@cpignedoli
Copy link
Member

cpignedoli commented May 26, 2023

I had no problems with my tests so from my side, despite I did not go through the files, I am OK with merging.
I just noticed a minor bug: in the viewer, if I click on an atom it does not get selected, but if I enter the ID in the selection tab and click "apply selection" it works. Did you experience something similar?

@unkcpz
Copy link
Member Author

unkcpz commented May 26, 2023

I just noticed a minor bug: in the viewer, if I click on an atom it does not get selected, but if I enter the ID in the selection tab and click "apply selection" it works. Did you experience something similar?

Not in the amd64 machine. Is it the nglviewer that needs to respond? Can you check the version of nglview.
But I'd like to tackle it in another PR. I want to merge this one and test #384, so there is no delay for the release.

@cpignedoli could you open an issue for it with one screenshot? Thanks!

@unkcpz unkcpz merged commit f742207 into main May 26, 2023
@unkcpz unkcpz deleted the arm64 branch May 26, 2023 09:23
danielhollas added a commit that referenced this pull request May 9, 2024
The goal of this change is twofold:
- Improve CI runtimes (currently the overall workflow takes ~1h40min!)
- Reduce complexity
I ended up reverting things back to where they were roughly around PR #372,
while (hopefully) keeping the current modularity. See more details in #439 
The workflow now takes ~20 minutes. 

Major changes:
- Don't upload images as artifacts, upload to ghcr.io straightaway.
  (this however does not support PRs from forks)
- The arm64 image is build on Ubuntu GHA runner with the help of QEMU virtualization. 
- Build and test on amd64 first to catch issues within first 6 minutes
- Only test full-stack for arm64
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants