[Feature]: Configurable Hostname Policy in CoreSMD (CoreDHCP Plugin)

[alexlovelltroy]

Describe the feature

Add configurable hostname generation to the CoreSMD CoreDHCP plugin to support multiple hostname strategies for DHCP Option 12 based on component type (and optionally subnet), without requiring changes to SMD.

Goals

• Allow hostname customization by Component.Type.
• Preserve current default behavior unless explicitly configured.
• Avoid any changes to SMD schema or data structures.
• Maintain O(1) lookup performance during DHCP handling.
• Keep configuration simple and explicit.

Non-Goals

• Modifying SMD data model.
• Introducing hostname persistence inside SMD.
• Dynamically mutating SMD during lease assignment.
• Complex rule engines.

Proposed CoreSMD config surface

Minimal (type-based) configuration

Add config keys to the CoreSMD coredhcp plugin:

• hostname_default= (optional; default empty → don’t set option)

• hostname_by_type= (repeated or comma-separated)

  • Example:

    • hostname_by_type=Node:nid{04d}
    • hostname_by_type=NodeBMC:bmc{04d}
    • hostname_by_type=MgmtSwitch:{id}
    • hostname_by_type=HSNSwitch:{id}

This directly leverages the existing pattern expander that supports {id} and {0Nd}. ([GitHub][12])

Extended (subnet-aware) configuration (aligns with issue #21)

Optionally introduce:

• hostname_by_subnet= where each subnet block contains type rules, e.g. YAML/JSON file:
  • hostname_policy_file=/etc/coresmd/hostname-policy.yaml

This lets you say: “on subnet A, nodes are nid####; on subnet B, nodes are fe-####”, while switches stay {id} everywhere.

Behavior

When responding to DHCPv4:

1. Resolve (MAC → ifaceInfo) (already done).

2. Determine hostnamePattern from:

   • subnet-specific rules (if enabled)
   • else type-based rules
   • else default

3. If non-empty, set:

   • resp.Options.Update(dhcpv4.OptHostName(hostname))

Code example (CoreSMD-side)

1) Represent the policy

// internal/hostnamepolicy/policy.go
package hostnamepolicy

import (
	"net"

	"github.com/openchami/coresmd/internal/hostname"
)

type Policy struct {
	DefaultPattern string            // may be ""
	ByType         map[string]string // Component.Type -> pattern
}

func (p Policy) HostnameFor(componentType string, nid int64, xname string) (string, bool) {
	pat := ""
	if p.ByType != nil {
		pat = p.ByType[componentType]
	}
	if pat == "" {
		pat = p.DefaultPattern
	}
	if pat == "" {
		return "", false
	}
	return hostname.ExpandHostnamePattern(pat, nid, xname), true
}

// (Optional future) subnet-aware wrapper.
type SubnetPolicy struct {
	Subnet *net.IPNet
	Policy Policy
}

ExpandHostnamePattern already supports {id} (xname) and {0Nd} formatting. ([GitHub][12])

2) Apply it in the DHCP handler

Conceptually (shown in v0.3.1 handler for where hostname is set): ([GitHub][3])

// inside Handler4 after ifaceInfo is resolved and assigned IP is chosen:

if hn, ok := hostnamePolicy.HostnameFor(ifaceInfo.Type, ifaceInfo.CompNID, ifaceInfo.CompID); ok {
	resp.Options.Update(dhcpv4.OptHostName(hn))
}

For slingshot switches, pattern = "{id}" yields the xname as the hostname.

For “fe-style” naming, pattern = "fe-{04d}" yields fe-0001, etc.

Example CoreDHCP config usage

Type-based only (simple)

server4:
  plugins:
    - coresmd:
        - svc_base_uri=https://smd.example/apis/smd
        - hostname_by_type=Node:nid{04d}
        - hostname_by_type=HSNSwitch:{id}
        - hostname_default=

Subnet-aware (future, paired with issue #21)

/etc/coresmd/hostname-policy.yaml

default:
  byType:
    HSNSwitch: "{id}"

subnets:
  - cidr: 10.1.0.0/16
    byType:
      Node: "nid{04d}"
  - cidr: 10.2.0.0/16
    byType:
      Node: "fe-{04d}"

Why do you want this feature?

Mixed HPC environments require different DHCP hostname behaviors for
different device classes.

• Slingshot switches require the DHCP hostname to equal their xname.
• Compute nodes typically require nid#### format.
• Some environments require custom prefixes (e.g., fe-####).

Current hostname handling in CoreSMD is not sufficiently flexible to
support all of these simultaneously without configuration changes.

Alternatives you've considered

1. Modifying SMD schema to store hostname preferences.
   • Rejected due to complexity and coupling DHCP logic into SMD.
2. Hard-coding additional device-specific rules.
   • Rejected because it does not scale or generalize.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[davidallendj]

How is Policy.ByType populated? Is that just reading from coredhcp config file and adding all of the hostname_by_type values and/or all the items under default.byType in /etc/coresmd/hostname-policy.yaml? It would have to happen before HostnameFor is called since it uses the policy.ByType to get the pattern to use for hostname.ExpandHostnamePattern.

[davidallendj]

Should this replace the existing node_pattern and bmc_pattern values in the config file or should that coexist? I noticed in the code with the way this is suggested that component types for Node and NodeBMC will always replace whatever is specified with hostname_by_type and hostname_default.

[synackd]

Reopening this as it hasn't been implemented yet.