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

Update to Omnia Linux anvil #761

Merged
merged 37 commits into from
May 15, 2017
Merged

Update to Omnia Linux anvil #761

merged 37 commits into from
May 15, 2017

Conversation

Lnaden
Copy link
Contributor

@Lnaden Lnaden commented Apr 17, 2017

Start the process for updating to the CentOS 6 image.

This is very much a work in progress since we cannot reasonably test all the packages at once. So this initial commit will be to make sure the basics of the new docker image work.

This that need to be done in loose order:

  • Ensure the docker image is pulled correctly, including EPEL 6
  • Ensure the conda-forge channel and packages are being fetched
  • Update some non-OpenMM dependent packages' build number to see if they can build on the new image (future PRs)
  • Remove packages which are in conda-forge that we dont need in omnia anymore (future PRs)

Replaces and closes #667

Tagging @jchodera

@Lnaden
Copy link
Contributor Author

Lnaden commented Apr 17, 2017

This keeps xcode on 6.4, no fix is in place

@Lnaden
Copy link
Contributor Author

Lnaden commented Apr 17, 2017

I have added files to serve as flags for removal, review, and other notes on various packages. Most of these are FLAG_FOR_REMOVAL files to indicate that the package can probably be removed since the package already exists as part of conda-forge. These should be reviewed and discussed though.

Allow openmoltools to build on windows
@jchodera jchodera mentioned this pull request Apr 18, 2017
Lnaden added 4 commits April 18, 2017 13:39
Attempt to get clang from clangdev of conda-forge for OpenMM
TEMPORARY: Made OpenMM build only on Linux and Python 3.5 for rapid testing
REMOVE THIS TEMP CHANGE BEFORE MERGE
@Lnaden
Copy link
Contributor Author

Lnaden commented Apr 19, 2017

Good news! The new docker image can successfully build OpenMM. I have also confirmed that it is correctly using clang as the compiler (which now comes from conda-forge and not an addon to the image, its finding and building the OpenMMCUDA targets so the CUDA toolkits are installed correctly, its finding and building the OpenMMOpenCL targets from the AMD SDK so those are also installed. The docs are being built which means the TeXLive kit is installed correctly as well.

This validates the docker image is constructed correctly and packages can be built on it. I think it we are ready to move onto testing other packages, removing my debug lines, start reviewing the packages for removal.

Also it would be good if someone else look at least at the docker file to make sure it gets everything we need.

@peastman
Copy link
Contributor

Yay!

@Lnaden
Copy link
Contributor Author

Lnaden commented Apr 19, 2017

@peastman is there a particular reason we need to keep OpenMM pinned to clang 3.8.1? They have clang 3.9.1 on conda-forge as well so this may be a decent time to reassess the compiler version if there is not some hard restriction.

@peastman
Copy link
Contributor

In general I'm fine with using the most recent version, but for releases it's important to know and control what compiler is used. For example, when we release a patch update to fix bugs, it needs to be built with the same compiler version as the release it's a patch to. Compiler updates have been known to introduce bugs.

@Lnaden
Copy link
Contributor Author

Lnaden commented Apr 19, 2017

Okay. I'll keep it pinned to 3.8.1 in the main omnia channel since we are not actually releasing a new version yet. We can reconsider the version for any planned major releases going forward. Thanks!

Removed debug lines
@Lnaden
Copy link
Contributor Author

Lnaden commented Apr 20, 2017

Okay, I have updated the README (could use some review @jchodera ), removed the debugging line, and set all the packages I think are ready for removal and review.

OpenMM builds on the new image, so I think we are ready to go with the migration to CentOS 6 based and conda-forge. I need to reach out to the CF people yet and figure out how to get things like the AMD SDK and the CUDA tools for actually taking OpenMM to CF, but one step at a time here.

When this PR merges: conda-forge will become a requirement for packages built after this PR

@Lnaden
Copy link
Contributor Author

Lnaden commented Apr 21, 2017

Okay, I fixed the OSX builds by not overwriting AppleClang with clangdev. But now there is a new problem.

OSX OpenMM build appears to complete, but not install correctly so the test fails to find the simtk package like it was not installed right. The linux builds are fine, but there should not have been a change to the osx side. Has anyone ever seen this issue? file here, search for run_test to get to the failure since its the raw log.

@peastman
Copy link
Contributor

No idea. I don't see any indications in the log of what the problem is. It runs the PythonInstall target, and appears to complete successfully:

[100%] Built target PythonInstall

When it gets to the test, it claims it's about to install the package it just built:

TEST START: /Users/travis/anaconda/conda-bld/osx-64/openmm-7.1.0rc1-py35_1.tar.bz2
...
The following NEW packages will be INSTALLED:
...
    openmm:          7.1.0rc1-py35_1  local

It doesn't report any errors while installing. Yet it then reports that OpenMM isn't installed:

===== testing package: openmm-7.1.0rc1-py35_1 =====
running run_test.py
Traceback (most recent call last):
  File "/Users/travis/anaconda/conda-bld/openmm_1492787167059/test_tmp/run_test.py", line 7, in <module>
    from simtk import openmm
ImportError: No module named 'simtk'
TESTS FAILED: openmm-7.1.0rc1-py35_1
ERROR: File does not exist: /Users/travis/anaconda/conda-bld/osx-64/openmm-7.1.0rc1-py35_1.tar.bz2

Possibly that last line is a clue? Should that file have been created?

@Lnaden
Copy link
Contributor Author

Lnaden commented Apr 21, 2017

Everything I see tells me it installed correctly, but it looks like the files just were not copied correctly.

Possibly that last line is a clue? Should that file have been created?

Sadly no, that is just the generic error that conda-build throws as the last step as it checks for the tarbal as its last action, independent of if something else failed.

I think this might be conda problem, I have some things I can test to find out.

@Lnaden
Copy link
Contributor Author

Lnaden commented Apr 21, 2017

I cannot find a way to build on OSX without conda-build just failing for some unknown reason. Moving the channel priority to later appears to break the conda-build-all script. There are no helpful errors. Will keep debugging

@Lnaden
Copy link
Contributor Author

Lnaden commented Apr 21, 2017

So the problem I am seeing on the OSX build is exactly the same problem we are seeing on the OpenMM Python 3.6 windows builds here: openmm/openmm#1758 (comment)

How to fix it though....

@Lnaden
Copy link
Contributor Author

Lnaden commented Apr 24, 2017

Okay, here is what I can tell from digging around on the net.....

The problem comes from the fact that python is built against a certain MACOSX_DEPLOYMENT_TARGET minimum which is separate from the environment variable. This appears to be tied to the python executable itself from what I can read (I think, there may be a way to change this).

When building new packages, the environment MACOSX_DEPLOYMENT_TARGET cannot be lower than the python that was used to compile it. So what we are seeing is the python we get on OSX for python versions not 3.4 are built against osx 10.9, then when we set the env MACOSX_DEPLOYMENT_TARGET, it complains and crashes.

There are some oddities with this though. My local version of Python 3.5.3 from default channel was built against macosx 10.7, but the same version of python 3.5.3 from conda-forge is built against osx 10.9. My guess is the version of python 3.4, which stopped getting updates, was built against the 10.6 osx, which is why we see this difference.

So now the question is, can we set the version to built against from the python compiler, or are we going to have to find that magic python version which is 10.7 compiled for each version of python.

On a side note, this is excessively dumb.

@jchodera
Copy link
Member

On a side note, this is excessively dumb.

+1000

@jchodera
Copy link
Member

Maybe this is a good time to report it on the conda-forge and possibly anaconda issue trackers to solicit advice?

@Lnaden
Copy link
Contributor Author

Lnaden commented Apr 24, 2017

Maybe this is a good time to report it on the conda-forge and possibly anaconda issue trackers to solicit advice?

Maybe, the problem is this does not appear to be a conda-related issue. I think this is a pure-python issue since I think setup.py scripts would throw this issue. Evidence here where the Python folk were pointing it out back in Python 3.2/3.3. This is my evidence that it looks like a Python deployed to a min version cannot deploy packages it builds to an even smaller min version.

@jchodera
Copy link
Member

It's conda-related insofar as the python versions made available in these channels were compiled with specific versions of the OSX frameworks, right?

Are all the conda-forge python versions built with 10.7 or earlier? If so, could we just

  • add the conda-forge channel
  • conda clean -pltis --yes to get rid of cached anaconda python installs
  • create a new env with the conda-forge python
  • then add other channels and build?

@Lnaden
Copy link
Contributor Author

Lnaden commented Apr 24, 2017

I just realized this conversation is happening on the wrong issue, linking back to the comment here

@Lnaden
Copy link
Contributor Author

Lnaden commented May 1, 2017

Hold off on merging this until OpenMM 7.1.1 is published at minimum

I think this is otherwise ready to go for the most part (some last builds running)

xref: #768

@jchodera
Copy link
Member

jchodera commented May 1, 2017

Should we at least disable the current failing byulds? I'm a separate pr?

@Lnaden
Copy link
Contributor Author

Lnaden commented May 1, 2017

I can and did for most of them already. The remaining errors being raised are legitimate concerns that I don't want to silence. They are mostly caused by lack of OpenMM on Python 3.6 for Windows that we never fixed. When we cut 7.1.1, we will want to fix that first.

@Lnaden
Copy link
Contributor Author

Lnaden commented May 1, 2017

And to be precise, the remaining errors are all related to missing OpenMM builds.

@Lnaden
Copy link
Contributor Author

Lnaden commented May 15, 2017

Guess what! Its merging day!

@Lnaden Lnaden merged commit a21c278 into master May 15, 2017
@jchodera jchodera deleted the linux-anvil branch December 4, 2017 22:17
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.

3 participants