We keep all of our machines in DNS with names that help us quickly and easily find them in our racks for repairs and replacements. Having to manually change the randomly generated names that MAAS creates to match our DNS names gets tedious for a few hundred nodes.
It would be nice to have MAAS first attempt to find a DNS name for a new node’s IP address and use it if available, and only if that fails have it fall back to generating a random name.
I’ve made a merge proposal with this feature implemented as a config option that we’ve been successfully using at our site. If anyone is interested in trying it out, you can find it here:
Here is a modified feature request, since the point was raised that there are many possibilities for what users might want as naming sources:
Have a config option for hostname_source that could be set to any one of a number of choices.
Have python-petname as the default (though it might be better to give it a generic name, e.g. “randomly_generated”, in case the underlying mechanism for generating random names changes in the future).
If the chosen hostname_source fails, have it fall back to randomly_generated.
Use the patch I linked as a starting point for one of the options. Maybe call it “ip_lookup”, since socket.gethostbyaddr() can call more than just DNS.
As other naming sources are implemented, e.g. sequential with a prefix, or MAAS system_id, or BMC rack info, or web endpoint responses, or whatever else people care to implement, they could be added as choices to hostname_source.
I’ve been using this feature for a couple of months now and it has been working great for us. Would be nice if it could be discussed for inclusion in the main branch.
I’m speaking for myself here, so other core maintainers might have different opinions. I would consider this feature for upstream only if we get positive feedbacks from multiple clients/users/contributors/stakeholders. I would not include this feature just because it fits the specific setup with such external DNS infrastructure of just one specific user.
One thing you have received is a number of requests over the years for different ways to set up node naming. I’d have to go digging to remember them all, but I remember seeing requests for sequential names, and for rack position names. I’m sure there have been more. Would you be more open to the part of the request that’s about adding some kind of name-choosing-plugin feature? That would be the common factor between all of the different “can our nodes be named this other way?” requests that you’ve received.
having a more meaningful name respect to the petname makes defintely sense, but honestly I’ve seen only your request about a DNS resolution to get the hostname.
If there are ideas about a naming that helps the user to identify a new/enlisted machine, then of course I think there is value that everybody from upstream could benefit from
Actually I’m thinking more about providing a way to change the name of a machine in a commissioning script via some API. This way every user could implement whatever custom/esoteric way to generate the name of the machine being commissioned.
Something like 99-my-custom-commissioning-script.sh where you can just use the node credentials already present in the commissioning environment to reach out to the regiond at /metadata/...TBD.../change-hostname in order to change the hostname of the machine
That sounds like it could work for us. I’m assuming that the commissioning script would be able to query the local IP address, and we should be able to do everything else we need based on that, as long as we can reach out to other services (e.g. DNS).
Let’s see… the previous requests I’ve seen for node naming variants:
I do like my “sharp-whale” and “free-yeti”. However, as default, I would like to give the nodes a more boring name <service-tag>-<i++>. But, if the assigned IP already has a DNS entry associated with it, the host should get that name.
Perhaps the script is the way to move forward, please elaborate.
<prefix>-<i++> is also what we use. Names in that form are what we’re pulling from DNS.
In fact, that’s been the naming pattern for compute clusters at every place I’ve worked at for the past 25 years, though it may be different in other industries. It’s always a prefix followed by a zero-padded number, something like:
Name ranges like that are easier to keep up-to-date and use than a long list of random names. It’s also easier to find the machines in the racks when they need service, and easier to remember how many machines of each type you have. It’s just a practical, workable choice, which I guess is why it has been so common in my experience.
Like the others here, our destination naming scheme is boring.
Something like
cx[01-15].domain fp[01-02].domain
etc.
That said, its unlikely that we can pre-determine these names.
what does happen, tho, is that the BMCs send their custom names in dhcp request, such that we receive things like idrac-XXXXX or ILOCZJXXXXX, which we map to names we consider sensible, which is <machine-type>-<counter>-bmc, for example r750-01-bmc, dl385-04-bmc, or as-4145gh-tnmr-01-bmc (thanks, supermicro -.-).
ideally I would like to have these bmc names w/o the bmc, in this case r750-01, dl385-04, or as-4145gh-tnmr-01, so we can identify them quickly and give them their assigned role name, (which would be gx04, tx03, and gx22 in this case, but that is unimportant here)