MPI data plane

[eisenhauer]

The way we're handling the MPI data plane currently is restrictive. The dataplane is not built if MPICH is not detected, and if you manage to force it to build, there is an #if defined(MPICH) in mpi_dp.c that automatically disables it.

Instead, we should always build the MPI data plane if MPI_open_port() is present in the in-use MPI library. If we're not confident that the MPI in use supports connecting disparate jobs, we should modify the value returned in MpiGetPriority() to something that would fall behind other DPs. This would allow users to try their MPI to see if it works without requiring source code changes.

[vicentebolea]

Fair point, the restrictiveness of the MPI dataplane was due to the avalanche of users issues that we got that were boiled down to just using MPI deployments that did not really support Client/Server comm, in addition to that we only targeted a few HPC systems and their MPI libs at that time. As times changes and projects evolves (MPI implementations), I can see that it is unreasonable to keep these restrictions. I will followup with changes that allows always building the MPI dataplane and set the priority of that dataplane to the lowest in MPI vendors/versions that are known to be difficult.