[LU-5881] Allow hostnames in NID

• Status: Resolved
• Project: Lustre
• Type: Improvement
• Priority: Minor
• Reporter: Amir Shehata (Inactive)
• Assignee: WC Triage
• Resolution: Duplicate

Description

Currently the NID is in the form <ip>@<net>. One possible improvement is to make it <hostname | ip>@<net>. This will allow abstraction of IP addresses, and possibly replacing nodes without having to change the configuration on other nodes.

Issue Links

• is related to: LU-5960 Add ability to get peer and connectio...
• is related to: LU-10359 remove NIDs from config llogs
• is related to: LU-10360 use Imperative Recovery logs for clie...
• is related to: LU-10391 LNET: Support IPv6

Comments

[Bob Glossman (Inactive)]

not all net types use an ip address as <nid>, and not all have a well known mapping method like hostname -> ip address for TCP/IP. whatever add on you do to allow transparent use of hostnames, you must be careful not to break addressing for other network types.

[Robert Read (Inactive)]

This is a useful feature, though it is not a full replacement of the dynamic NID idea which has been discussed before. Dynamic NIDs would allow the NIDs for targets to be discovered when the targets connect to the MGS, and not be stored in the configuration. This would allow a target to be failed over to any NID.

[Gene Campbell (Inactive)]

Hi Amir, Robert,

I'm curious what user scenario this addresses? Might be obvious to you. Or, restated, what problem does it solve for someone to have this feature, or what goal does it allow them to achieve?

Using hostnames allows abstraction to the specification of a host. Is the idea that you can configure your targets once, with a name, and then "tie" them to a host later with DNS? If that is the nuts and bolt, what is the actual user need? I'm assuming the user in this case is a Lustre admin.

[Doug Oucharek (Inactive)]

I'm attaching the slides I presented in the 2013 LUG on Dynamic NIDs. These may help answer some questions as to why we need a name to NID mapping.

[Robert Read (Inactive)]

We should support dynamic NIDs directly and not rely on Dynamic DNS. NID mapping is something that should just work out of the box and not requiring more external configuration. This is an opportunity to greatly simplify one of the more difficult aspects of Lustre configuration. But if we add yet another third party dependency we're just increasing the complexity and fragility of our stack, and limiting it's usability to sites that can support. This makes things harder, not easier.

[Andreas Dilger]

We can already use <hostname>@<net> for NIDs with mount.lustre and mkfs.lustre, but they are translated to <IPv4>@<net> before being passed to the kernel.

It isn't clear if there is a need for this ticket, or if it is redundant with LU-10359 and could be closed?

[Andreas Dilger]

Prefer not to store static NIDs or hostnames in the config log at all...