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
test/datatype: do not use installed components #12285
base: main
Are you sure you want to change the base?
Conversation
By default, the tests will use the components in the build directory but also in the installation directory if any. That can cause some bizarre issues when they are not compatible. Thanks Kook Jin Noh for the initial bug report. Refs. open-mpi#12282 Signed-off-by: Gilles Gouaillardet <gilles@rist.or.jp>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've honestly had this issue for years, and always made sure to just not have an installed OMPI available. I kinda like this solution better.
It took me a while to understand what this change is doing on the tests. We should document this change better. Btw, how are the tests using the components in the build directory ? We load them using the install_dir, we don't even know the build path for each component. If we include everything into libmpi.so then this should not be a problem, but if we build shared library components we default to first opening the install path location components. |
Well, shame on me! the tests do not use the components from the build directory, and with this patch, it does not open any component at all, which happens to be ok for I will double check that tomorrow and fix the commit message. |
It's quite possible that we don't have any |
Thanks @rhc54 for fixing the param file issue in openpmix/openpmix#3273, I will backport the fix to Open MPI. |
I am not completely convinced by this. Preventing the use of components from an old installation (especially one that is not binary compatible internally), is a desired features, but this way of doing it is a little too strict. On a default build (all components included in the But in the case where we build with full support for shared libraries, aka. all components are in separate The issue #12282 talks about OMPI 5.x loading components from an OMPI 4.1 installation. I don't understand how that can happen because I was under the impression that we prevent the opening of components with an incorrect version. |
I just found that the The issue is triggered by the My theory is that since You are definitely correct about static vs dynamic components. In the example you described, I guess |
Hmmm...I wonder if it would make sense to add a check in the ext3x component so it Won't help the OMPI v4 stuff that is out in the wild, but maybe help down the road? FWIW: the MCA version didn't change because there was no modification to the MCA interface itself, so the plugins are in fact compatible. |
I do not think the From the point of view of Open MPI v5, the |
Given that fixing OMPI v4 won't help with all the outstanding installations, maybe the right (but perhaps ugly) solution is to add some in the OMPI v5 mca base that just says "if you find a PMIx component, ignore it". I believe that is the solution you prototyped, yes? Makes the best sense to me! |
One of the root causes of this is that we However, other issues persist:
@ggouaillardet this approach will not solve the problem as non-yet-installed components. In fact the only solution to it would be to always build the accelerator_null component statically. We'll chat about this on our slack channel and come back with a solution. |
By default, the tests will use the components in the build directory but also in the installation directory if any. That can cause some bizarre issues when they are not compatible.
Thanks Kook Jin Noh for the initial bug report.
Refs. #12282