Skip to content

Hypervisor node bootstrapping simplification #128

Description

@lukasfrank

Summary

Bootstrapping a hypervisor node today means aligning several independent artefacts:

  • the OS image
  • the provider image
  • ignition
  • kustomizations

Currently, we don't have a single artefact that describes "a node ready to host VMs." This roadmap item aims to make node bootstrapping simpler and more reliable by shipping more of the hypervisor stack in the OS image itself and streamlining the dependency chain between these artefacts.

The goal is to have a clear split:

  • configuration lives in ignition
  • everything else: the hypervisor stack and the ironcore providers in the OS image

This builds on the new ironcore-image format proposed in IronCore Image V2 (IEP).


Scope

In Scope

  • OS Image with a preinstalled hypervisor stack (e.g. libvirt), building on the new ironcore-image format.
  • Decision + evaluation on whether to bake ironcore providers into the OS image (e.g. libvirt-provider, dpservice, etc.).
  • Reworking ignition and kustomizations so that ignition carries only configuration and the OS image carries everything else.

Out of Scope

  • The new ironcore-image format itself, defined in IronCore Image V2 (IEP)
  • The metaldata service design (tracked in IEP-18).
  • Bare-metal provisioning / metal-operator changes beyond what bootstrapping
    requires.

Responsible Areas

  • Metal Automation
  • Virtualization
  • Networking

Contributors


Acceptance Criteria

  • Operating System / OS Image

    • An OS image variant with a preinstalled hypervisor stack is published in
      os-images.
  • Virtualization

    • Compute components (e.g. libvirt-provider and poollet) ship in the OS image.
    • libvirt-provider offers systemd units
    • provider exposes endpoints to "observe" it
  • Networking

    • Networking components (e.g. dpservice / metalnet) ship in the OS image.
  • Storage

    • Storage components (e.g. Ceph client / ceph-provider prerequisites) ship in the OS image.
  • Common

    • Configuration is carried by ignition only; the rest ships in the OS image.

Action Items

  • Assign labels (e.g., area/ironcore-api, kind/design)
  • Set milestone (e.g., H1/2025)
  • Assign dependent sub-issues in each required area
  • Assign an owner to the issue using the GitHub "Assignee" field
  • List all contributors in the "Contributors" section above
  • Add this issue to the Roadmap project board

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/computeCompute and virtualization specific issues and enhancements.area/iaasIssues related to IronCore IaaS development.kind/roadmapIssues that should show up on the CNTF Org level roadmap and cover activities with key stakeholders.

    Projects

    • Status
      No status
    • Status
      Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions