On 9/6/06 9:44 AM, "Christian Kauhaus" <ckauh...@minet.uni-jena.de> wrote:
> Bogdan Costescu <bogdan.coste...@iwr.uni-heidelberg.de>:
>> I don't know why you think that this (talking to different nodes via
>> different channels) is unusual - I think that it's quite probable,
>> especially in a heterogenous environment.
>
> I think the first goal should be to get IPv6 working -- and this is much
> more easier when we restrict ourselves to the case when all system
> participating in one(!) job are reachable via a single protocol version,
> either IPv4 or IPv6.
>
> I'm not quite sure if we need to run a *single* job across a network
> with both systems that are not reachable via IPv4 and systems
> that are not reachable via IPv6. If there is a practical need for this,
> we will probably tackle this in the future. Note that the current plan
> does not restrict the use of OpenMPI in heterogenous IPv4/IPv6
> environments, but we will not support mixed IPv4/IPv6 operation in a
> single job right now.
>
> Our current plan is to look into the hostfile and see if there are
>
> (1a) just IPv4 addresses
> (1b) IPv4 addresses and hostnames for which 'A' queries can be resolved
> (2a) just IPv6 addresses
> (2b) IPv6 addresses and hostnames for which 'AAAA' queries can be resolved.
>
> In case 1 we initially use an IPv4 transport and in case 2 we initially
> use an IPv6 transport for the oob. If neither case 1 or 2 are possible,
> we abort.
>
Actually, that could cause us considerable problem. Only a subset of OpenRTE
and OpenMPI users actually have hostfiles - the majority do not. Hence, if
we base the IPv6 operation on what is in a hostfile we will be in trouble.
I believe we are going to have to use the "select" mechanism of the OOB
and/or the RML frameworks to let us know which protocol to use when talking
to a specific host.
I also believe you cannot assume that this choice will be consistent for all
processes involved in a job. For example, the head node process must talk to
the external network, which may well be IPv6. However, the nodes *inside*
the cluster may well be IPv4 since they could likely be sitting on a NAT.
The HNP still needs to talk to those nodes as well as the external network.
I don't believe that letting both modes co-exist is all that much harder a
problem to solve. We have similar situations elsewhere in the code base and
have found that the framework mechanism works very well in this situation.
I need to answer Adrian's note anyway and will describe there how to handle
multiple component operations.
> I hope that all can agree that this is a good starting point.
>
> Regards
> Christian
