https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-5881 Lustre <p>Currently the NID is in the form &lt;ip&gt;@&lt;net&gt;. One possible improvement is to make it &lt;hostname | ip&gt;@&lt;net&gt;. This will allow abstraction of IP addresses, and possibly replacing nodes without having to change the configuration on other nodes.</p> LU-5881

Allow hostnames in NID

Improvement Minor Resolved Duplicate WC Triage Amir Shehata Thu, 6 Nov 2014 23:13:44 +0000 Mon, 8 Jan 2024 20:48:39 +0000 Mon, 8 Jan 2024 20:48:39 +0000 0 10 <p>not all net types use an ip address as &lt;nid&gt;, and not all have a well known mapping method like hostname -&gt; 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.</p> <p>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. </p> <p>Hi Amir, Robert,</p> <p>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? </p> <p>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.</p> <p>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.</p> <p>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. </p> <p>We can already use <tt>&lt;hostname&gt;@&lt;net&gt;</tt> for NIDs with <tt>mount.lustre</tt> and <tt>mkfs.lustre</tt>, but they are translated to <tt>&lt;IPv4&gt;@&lt;net&gt;</tt> before being passed to the kernel.</p> <p>It isn't clear if there is a need for this ticket, or if it is redundant with <a href="https://jira.whamcloud.com/browse/LU-10359" title="remove NIDs from config llogs" class="issue-link" data-issue-key="LU-10359">LU-10359</a> and could be closed?</p> <p>Prefer not to store static NIDs or hostnames in the config log at all...</p> Related LU-5960 LU-10359 LU-10360 LU-10391 Development Rank 1|hzx0fz: Rank (Obsolete) 16445