test(live): prove the btrfs fixture kernel on the remote lane and name BTRFS_FS in the spine preflight

Open
  • Is something wrong?
#3,580 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
kubernetes, linux, python
Domain
devops, testing

Research direction

Read tests/integration/live_stack/spine.py around lines 752-774, tests/integration/live_stack/test_spine.py, and the two named live testing runbooks. First rebuild the fixture kernel in a fresh output directory and run a remote-libvirt live cell on sys-R1 against the btrfs-root Fedora base; record whether it reaches ready. If it passes, add the BTRFS_FS preflight case and update the runbooks; if it fails, record the cause and leave the preflight unchanged.

Written by the indexing model from the issue text.

Description

area:build-install effort:S priority:P3 risk:daytime-only status:ready type:test

Problem

#3519 (PR #3560) added CONFIG_BTRFS_FS=y to the fixture fragment and documented it, but two items stayed open by design: (1) no Run was provisioned to ready on the remote-libvirt live lane with a kernel built from the fragment against a btrfs-root Fedora base; the PR proved only a direct-QEMU boot (positive and negative control); (2) the spine kernel preflight still rejects root_fs="btrfs", so a fixture kernel lacking the driver ends as boot_timeout with no named symbol. #3519's scope allowed (2) only if a live cell passes it.

Evidence

  • tests/integration/live_stack/spine.py:752-753: root_fs accepts only None, ext4, xfs (SpinePhaseError otherwise); :767-774 map ext4/xfs to EXT4_FS/XFS_FS; no BTRFS_FS branch.
  • docs/operating/runbooks/live-testing.md:1003-1006 states no kernel preflight names the btrfs driver.
  • docs/operating/runbooks/remote-live-stack.md:37-39 repeats it.
  • PR #3560 body, "Not run: the remote-libvirt live lane"; WORK:TRAJECTORY on #3519: "the issue's preflight half is open".

Expected

A kernel built from the pinned fragment reaches ready on the remote-libvirt live lane against the btrfs-root Fedora base, recorded as a live cell. The spine preflight accepts root_fs="btrfs" and names CONFIG_BTRFS_FS=y when absent.

Proposed approach

  1. Rebuild the fixture kernel into a fresh output directory (per the #3560 docs; old trees do not rebuild) and run one remote-libvirt live cell with it on sys-R1; record the result.
  2. If it passes, add btrfs to the accepted root_fs set mapping to BTRFS_FS, with a unit case in tests/integration/live_stack/test_spine.py, and drop the "no preflight names" sentences from the two runbooks.
  3. If it fails, record the cause instead and leave the preflight unchanged.

Provenance

Follow-up from campaign 4c2c8dc9e59d-7f9a87f5-2251-458a-bb30-04fbb2d4b05c. Source: #3519 / PR #3560.

Dominant language
Python
Stars
0
Forks
0
Avg merge
9h 13m
Merged PRs (30d)
197

Getting set up

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.

More from randomparity/kdive

All issues in randomparity/kdive

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.