Add hostname propagation to ironcore-net NetworkInterfaces

[ushabelgur]

Proposed Changes

• Pass machineName as hostaname to ironcore-net NetworkInterfaces while creating machine
• Update testcase
• Update ironcore-net dependency

Fixes #538

Summary by CodeRabbit

• New Features

  • Network interfaces optionally accept hostnames; hostnames are now populated automatically from machine guest configuration to improve network identification.

• Chores

  • Bumped Go toolchain, vendor dependencies, and pinned build/tooling versions used for codegen and tests.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b1e232da-b661-48cc-8aa9-c5be79b43b0e

📥 Commits

Reviewing files that changed from the base of the PR and between 2474f40 and 6a96762.

⛔ Files ignored due to path filters (1)

• go.sum is excluded by !**/*.sum

📒 Files selected for processing (5)

• Makefile
• api/machine.go
• go.mod
• internal/plugins/networkinterface/apinet/apinet.go
• internal/server/machine_create.go

---

📝 Walkthrough

Walkthrough

Adds an optional HostName field to NetworkInterfaceSpec, sets it from the machine GuestConfig during machine creation, and includes it when applying APInet NetworkInterface; also bumps Go/Kubernetes dependencies and pinned tool versions.

Changes

Hostname propagation

Layer / File(s)	Summary
API type and machine creation api/machine.go, internal/server/machine_create.go	NetworkInterfaceSpec gains HostName string (hostName,omitempty). Machine creation extracts GuestConfig.Hostname (when present) and sets HostName on each api.NetworkInterfaceSpec.
APInet plugin apply internal/plugins/networkinterface/apinet/apinet.go	APInet apply-configuration builder now sets Hostname from spec.HostName, uses apinetClient.Apply(...) and then Get(...) to retrieve the applied NetworkInterface.
Dependency upgrades (go.mod) go.mod	Bump go directive and multiple direct/indirect dependencies including github.com/ironcore-dev/ironcore and k8s.io/* / sigs.k8s.io/controller-runtime versions.
Pinned tool versions Makefile	Update CONTROLLER_TOOLS_VERSION and ENVTEST_VERSION defaults used for codegen and envtest downloads.

Sequence Diagram

sequenceDiagram
    participant Client
    participant MachineCreate as Machine Create Handler
    participant APISpec as NetworkInterfaceSpec
    participant APINETPlugin as APINet Plugin
    participant IronNetAPI as IronCore-Net API

    Client->>MachineCreate: Create Machine request
    MachineCreate->>APISpec: Construct NetworkInterfaceSpec
    MachineCreate->>APISpec: Set HostName (from GuestConfig.Hostname)
    MachineCreate->>APINETPlugin: Request NIC creation with Spec
    APINETPlugin->>APISpec: Read HostName from Spec
    APINETPlugin->>IronNetAPI: Apply NetworkInterface (includes Hostname)
    IronNetAPI->>APINETPlugin: Return applied NetworkInterface
    APINETPlugin->>IronNetAPI: Get applied NetworkInterface
    APINETPlugin->>MachineCreate: Return result
    MachineCreate->>Client: Respond Machine created

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: adding hostname propagation to ironcore-net NetworkInterfaces, which aligns with the actual code modifications across multiple files.
Description check	✅ Passed	The description follows the template structure with three bullet points covering the main changes and correctly references issue #538, though it contains a minor typo ('hostaname').
Linked Issues check	✅ Passed	The code changes fully implement issue #538 requirements: hostname field added to NetworkInterfaceSpec, propagated from machine name during creation, and APInet plugin updated to set hostname on NetworkInterface objects.
Out of Scope Changes check	✅ Passed	All changes are in scope: API extension for hostname, dependency updates (ironcore, Kubernetes packages), build tool versions, and hostname propagation logic. No unrelated modifications detected.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch enh/hostname

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

• Generate code and open pull requests
• Plan features and break down work
• Investigate incidents and troubleshoot customer tickets together
• Automate recurring tasks and respond to alerts with triggers
• Summarize progress and report instantly

Built for teams:

• Shared memory across your entire org—no repeating context
• Per-thread sandboxes to safely plan and execute work
• Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

internal/server/machine_create.go (1)

57-67: ⚠️ Potential issue | 🔴 Critical

HostName field will be empty string because iriMachine.Metadata.Id is not populated in requests.

At line 64, the HostName is set to iriMachine.Metadata.Id, but the IRI request's Metadata object never includes an Id field—it's only present in the response after being generated by the server. All test cases confirm that incoming Machine.Metadata contains only labels, not an id.

The PR objective states "Pass machineName as hostname," but the IRI Machine request provides no machine name field. The available option in the request is the Labels map (which contains a UID label, not a human-readable name). The server's generated internal ID at line 71 comes too late and is not the IRI machine's identifier anyway.

To fix this: determine whether to use a label value (if machine name is stored there), or reconsider the approach for obtaining the machine identifier at the point where NetworkInterfaceSpec is created.

[afritzler]

[afritzler]

/ref ironcore-dev/ironcore#1454

[ushabelgur]

@lukasfrank @afritzler should I introduce GuestConfig type for libvirt machine type? or only HostName is fine for now ?

[friegger]

I think it is a good idea to keep it consistent with the IRI side and introduce the GuestConfig. Though, not on the NetworkInterfaceSpec, but on the MachineSpec, like on the IRI side. Reasoning is, that there can be multiple NICs and with that we would introduce a possibility of a bug with inconsistent hostnames accross multiple NICs. Something that should be one, would be many. The apinet plugin has also access to the machine, so it can take the hostname there from the machine's GuestConfig. @lukasfrank What do you think?