cray native launch broken

[hppritcha]

Commit a0487e0 broke native launch on cray. I'm Implementing a cray native launch specific oob component to wall off these kins of problems from aprun users. When launching with aprun , there is
no need for any oob support from orte anyway.

The usock doesn't work on most cray's since getpwuid doesn't typically work on crya compute nodes.

@hjelmn

[rhc54]

How will you handle connect/accept operations via the MPI standard, which allows the user to specify a port by which to reach the other processes?

Or are you going to declare that MPI-2 dynamics ops are not available on the Cray?

[hppritcha]

MPI-2 connect/accept is not available with native launch on cray for open mpi. It is available for craypich, but mpich passes the portname directly down to all available netmods, but it doesn't look like the current orte_dpm does. A given mpich netmod will have its own portname format, which in the case of craypich, supplies all the info needed to build up connections over the gni fabric.

I'd just write a cray specific component if we needed it.

[rhc54]

Guess I'm now confused: when you say "native" launch, do you mean launching with mpirun, or launching with aprun? If the only thing blocking use of usock during mpirun-based launch is getpwuid, then that is easy to workaround - much easier than writing yet another OOB component.

We used to have that support anyway if you provided the -disable-getpwuid configure option. Did that get broken or go away?

[hppritcha]

I mean launching with aprun. The fact that getpwuid doesn't work on most production crays means the usock doesn't work, and the recent change you did disqualifies the tcp oob too. That's how things broke.

Already wrote the component and testing.

[rhc54]

Huh? That makes no sense - if we launch via aprun, then we are in a direct launch scenario. This is the only time the app retains the tcp oob component. So how did this break? Are you not using the ess/pmi component when direct launching under aprun?

[rhc54]

FWIW: usock is the sole method for the proc to talk to the local daemon when we launch via mpirun. So if usock won't work on the Cray due to the getpwuid issue, then it would be launch via mpirun that would break. The commit I made would indeed break that mode of operation - not direct launch.

It sounds like you may be chasing the wrong problem. A simple #if ENABLE_GETPWUID would solve the problem.

[hppritcha]

Yep, I agree about the mpirun launch problem. Only a matter of time before Nathan picks the commit up and discovers this too.

I'm mainly interested in making sure the aprun launch method works.

[hppritcha]

You broke things by addition of lines 454-459 in orte/mca/oob/tcp/oob_tcp_component.c

[rhc54]

Right - those only affect mpirun-based launch. Easy enough to make usock work when getpwuid isn't available - I can do that if you want.