ironcore-dev / ironcore-dev/roadmap

Lean Server / ServerClaim Core

Open
#120 1 comment 0 reactions 2 assignees View on GitHub

@adracus is already working on this.

Since Jul 21, 2026.

area/metal-automation kind/roadmap sovereign-cloud
Dominant language
Shell
Stars
1
Forks
1
PR merge metrics
No merged PRs in 30d

Description

Summary

The Server resource is overloaded. Today it is three things at once: a scheduling primitive (claim placement, cordon, state machine), a BMC client surface, and a boot-orchestration hub. Its reconciler talks to the BMC directly, writes power,
drives ServerBootConfiguration, and bootstraps discovery via Endpoint, all in one place.

The core problem: there is no seam between the scheduling primitive and the hardware. Power is written from the core reconciler, boot is hardcoded, and discovery is welded to Endpoint. Because all of this lives together, there is
no clean boundary where a different backend or a different owner can step in. The maintenance operator, for example, has no clean place to take over power and boot.

The maintenance roadmap #119 moves the maintenance machinery (ServerMaintenance / BMC* / BIOS*) into metal-maintenance-operator and introduces the typed maintenance contract. This issue is the other half: shrink Server and ServerClaim to a scheduling primitive behind an abstract interface, retire ServerBootConfiguration and boot-operator, drop the BMC, power, boot, and BIOS fields from Server, and replace Endpoint-based discovery with a boot-tool-driven flow.

This amends two decisions on #119: ServerBootConfiguration stays, and Endpoint stays in metal-operator. Both flip here, after the maintenance work has landed.


Scope

In Scope
  • Reconciler interface. A typed seam between the reconcilers and the BMC backend, so the core does not talk to the BMC directly. One writer of power in the cluster, and it is the maintenance operator.
  • Kill ServerBootConfiguration. The boot tool becomes the only boot path; boot-operator retires.
  • Slim Server CRD. Remove BMC, power, boot, and BIOS fields from Server.spec. Server keeps identity, capacity, scheduling state, conditions, and observed power state.
  • New discovery. BMC is the source of truth for "a server exists". Endpoint and the Initial state go away; the BMC reconciler seeds Server directly in Discovery.
  • Boot tool. A single, reusable, controlled path for booting a Server to a chosen image, with the image as the source of truth for the boot mode.
  • Cross-cutting. Deprecation calendar, chart pinning, cross-repo e2e, migration tools and docs.
  • Enhancement proposals. Each change lands a written proposal in ironcore-dev/enhancements before implementation.
Out of Scope
  • The maintenance contract itself, that is #119. This issue consumes it.
  • Changing the wire-level Redfish/gofish layer.
  • API churn unrelated to the field removals.

Responsible Areas

  • Metal Automation

Contributors

  • @afritzler
  • @adracus

Acceptance Criteria

  • Boot tool
    • Single reusable path for booting a Server to a chosen image, driven by the image's boot identity.
  • Reconciler interface
    • Reconcilers depend on the seam, not the BMC backend directly.
  • Remove ServerBootConfiguration + retire boot-operator
    • The boot tool is the only boot path.
    • ServerBootConfiguration removed; boot-operator archived.
  • Slim Server CRD
    • BMC, power, boot, and BIOS fields removed from Server.spec, each with a documented new owner.
  • New discovery
    • Endpoint removed; Initial state removed.
    • BMC reconciler seeds Server directly in Discovery.
  • Cross-cutting
    • Single deprecation calendar across #119 and this issue.
    • Cross-repo kind-based e2e covers the joint flow.
  • Common
    • Suggested order honored: boot tool -> reconciler interface -> kill ServerBootConfiguration -> slim Server, parallel with move BMC*/BIOS* -> new discovery. Cross-cutting runs throughout.
    • Coordination plan with metal-maintenance-operator for the two amendments to #119.

Action Items

  • Assign labels (e.g., area/metal-automation, kind/design, kind/api-change)
  • Set milestone
  • Open one tracking issue per change
  • Cross-link with #119
  • Add this issue to the Roadmap project board

References

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.