feat(kubevirt): expose migration configuration through platform values - #4254

## What this PR does

Document the optional `kubevirt.migrations` platform value, its empty
default, and the path from the parent platform Package to the rendered
KubeVirt CR. Include a `625M` / two cluster-wide migrations / one
outbound migration per node example and explain that bandwidth
quantities are bytes per second.

Only the unreleased `next` reference changes. This is the documentation
companion to
[cozystack/cozystack#4254](cozystack/cozystack#4254),
which exposes `kubevirt.migrations`; merge that implementation first.
This adds the migration settings to the existing KubeVirt section
alongside `kubevirt.disabledFeatureGates` from #678.

Validation:

- `bash hack/check-i18n.sh check` passed: 29 translation keys and 20
tracked translated pages.
- Checked the rendered KubeVirt reference section contains both existing
feature-gate documentation and the migration values, YAML example, and
bandwidth units.
- `git diff origin/main...HEAD --check` passed after merging current
`main`; the PR changes one reference file.
- Full Hugo 0.164.0 extended development build passed with `next`
included (2,032 pages across five languages); the rendered KubeVirt
section contains the table, YAML example and units.


### Screenshots

Not applicable; reference documentation only.

### Downstream repositories

- [x] No downstream repository is affected by this change
- [ ] [cozystack/website](https://github.com/cozystack/website) -
follow-up:
- [ ]
[cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack)
- follow-up:
- [ ]
[cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack)
- follow-up:
- [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up:
- [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up:
- [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) -
follow-up:
- [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) -
follow-up:
- [ ]
[cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server)
- follow-up:
- [ ]
[cozystack/external-apps-example](https://github.com/cozystack/external-apps-example)
- follow-up:
- [ ] [cozystack/examples](https://github.com/cozystack/examples) -
follow-up:
- [ ] [cozystack/community](https://github.com/cozystack/community) -
follow-up:

This reference-only change does not alter any downstream API, schema,
build tooling, installer setting or runtime behavior. The companion
Cozystack implementation is a prerequisite, not a downstream change
caused by this documentation.

### Release note

```release-note
docs(platform-package): Document cluster-wide KubeVirt migration configuration through kubevirt.migrations, including bandwidth units and parallel migration limits.
```

Backport of cozystack#4254 to release-1.6.

Cluster-wide migration settings could only be applied by patching the KubeVirt
CR: the kubevirt chart did not render `migrations`, and the platform bundle did
not forward it. The optional `kubevirt.migrations` platform value now passes
through the generated Package to `spec.configuration.migrations`, and a hand
patch of that Package is undone on the next platform render, so this hop is the
only supported setter.

Four differences from main, all from release-1.6 predating the
disabledFeatureGates work:

- platform values gains a `kubevirt` block holding `migrations` alone, and the
  iaas bundle gains only the migrations hop;
- the wiring test takes the four migrations cases and the case for a null
  `kubevirt` block, without the assertions that belong to disabledFeatureGates
  cases absent here;
- update_idempotency_test.sh gains `run_update_logged`, which arrived on main
  alongside that work and the new cases need;
- the kubevirt Makefile header counts six sed patches rather than five.

Verified on this branch: 9 kubevirt chart tests, 31 platform wiring tests (102
across the platform suite), and update_idempotency_test PASS under GNU make and
sed. Removing the new awk guard from the Makefile turns that test red naming the
migrations block, so the ported guard is not decorative. On this line
(.Values.kubevirt).migrations is the only reader of .Values.kubevirt, and
rewriting it as .Values.kubevirt.migrations turns the null-block case red with a
nil pointer.

The automated backport in cozystack#4322 stopped with conflict markers in four files as
its only commit, which is why this exists.

Assisted-by: LLM
Signed-off-by: Yan Bondarenko <[email protected]>

The sentence cozystack#4254 left behind says the device and CPU payload lines stay
outside the marker checks, which reads as if the rest are handled. The
extraFeatureGates entry is neither device nor CPU and is not covered either:
deleting `      - {{ . }}` under its range on a copy of the CR and running
`make update CR_FILE=<copy>` exits 0 and leaves the range wrapped around
nothing, with no check firing. The sentence it replaced covered that case.

Assisted-by: LLM
Signed-off-by: Yan Bondarenko <[email protected]>

…4340)

## What this PR does

Follow-up to a review comment on #4254 that was right and landed after
the merge.

The sentence that PR left in `packages/system/kubevirt/Makefile` says
the device and CPU payload lines stay outside the marker checks, which
reads as if the rest are handled. The `- {{ . }}` entries inside the
`extraFeatureGates` and `disabledFeatureGates` ranges are neither device
nor CPU and are not covered either. Deleting either of them from a copy
of the CR and running `make update CR_FILE=<copy>` exits 0 and leaves
the range wrapped around nothing, with no check firing; dropping `-
Template` from a clean copy fails the target as a control.

The wording now names every uncovered payload line: the device tables,
the `cpuAllocationRatio` value and both feature-gate entries, and keeps
`migrations` as the one block validated whole. Covering those payloads
in code is a wider change; happy to do it separately if that is wanted.

### Screenshots

Not a UI change.

### Downstream repositories

Comment-only change in one Makefile.

- [x] No downstream repository is affected by this change

### Release note

```release-note
NONE
```


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Documentation**
  * Clarified update validation guidance for disabled-feature markers.
* Documented partial-block recovery requirements and the workflow for
restoring missing markers.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Backport of #4254 to release-1.6.

Cluster-wide migration settings could only be applied by patching the KubeVirt
CR: the kubevirt chart did not render `migrations`, and the platform bundle did
not forward it. The optional `kubevirt.migrations` platform value now passes
through the generated Package to `spec.configuration.migrations`, and a hand
patch of that Package is undone on the next platform render, so this hop is the
only supported setter.

Four differences from main, all from release-1.6 predating the
disabledFeatureGates work:

- platform values gains a `kubevirt` block holding `migrations` alone, and the
  iaas bundle gains only the migrations hop;
- the wiring test takes the four migrations cases and the case for a null
  `kubevirt` block, without the assertions that belong to disabledFeatureGates
  cases absent here;
- update_idempotency_test.sh gains `run_update_logged`, which arrived on main
  alongside that work and the new cases need;
- the kubevirt Makefile header counts six sed patches rather than five.

Verified on this branch: 9 kubevirt chart tests, 31 platform wiring tests (102
across the platform suite), and update_idempotency_test PASS under GNU make and
sed. Removing the new awk guard from the Makefile turns that test red naming the
migrations block, so the ported guard is not decorative. On this line
(.Values.kubevirt).migrations is the only reader of .Values.kubevirt, and
rewriting it as .Values.kubevirt.migrations turns the null-block case red with a
nil pointer.

The automated backport in #4322 stopped with conflict markers in four files as
its only commit, which is why this exists.

Assisted-by: LLM
Signed-off-by: Yan Bondarenko <[email protected]>

Backport of #4254 to release-1.6.

Cluster-wide migration settings could only be applied by patching the KubeVirt
CR: the kubevirt chart did not render `migrations`, and the platform bundle did
not forward it. The optional `kubevirt.migrations` platform value now passes
through the generated Package to `spec.configuration.migrations`, and a hand
patch of that Package is undone on the next platform render, so this hop is the
only supported setter.

Four differences from main, all from release-1.6 predating the
disabledFeatureGates work:

- platform values gains a `kubevirt` block holding `migrations` alone, and the
  iaas bundle gains only the migrations hop;
- the wiring test takes the four migrations cases and the case for a null
  `kubevirt` block, without the assertions that belong to disabledFeatureGates
  cases absent here;
- update_idempotency_test.sh gains `run_update_logged`, which arrived on main
  alongside that work and the new cases need;
- the kubevirt Makefile header counts six sed patches rather than five.

Verified on this branch: 9 kubevirt chart tests, 31 platform wiring tests (102
across the platform suite), and update_idempotency_test PASS under GNU make and
sed. Removing the new awk guard from the Makefile turns that test red naming the
migrations block, so the ported guard is not decorative. On this line
(.Values.kubevirt).migrations is the only reader of .Values.kubevirt, and
rewriting it as .Values.kubevirt.migrations turns the null-block case red with a
nil pointer.

The automated backport in #4322 stopped with conflict markers in four files as
its only commit, which is why this exists.

Assisted-by: LLM
Signed-off-by: Yan Bondarenko <[email protected]>

… through platform values (#4402)

This reopens a fork backport from a branch in this repository so its CI
can run. The commit is the one from #4339 by @yankawai, unchanged. On
release-1.6 the pull-request CI pushes the images it builds, and a run
from a fork has no registry credentials, so #4339 stopped at the build
jobs and never reached e2e. The description below is the author's.

## What this PR does

Manual backport of #4254 to `release-1.6`.

The automated backport, #4322, stopped with conflict markers in four
files as its only commit, so it is red on DCO and unmergeable as it
stands.

Every conflict has the same cause: the `kubevirt.disabledFeatureGates`
work landed on main after 1.6 was cut, and the cherry-pick carried it
into hunks this line does not have. Four differences follow:

- platform values gains a `kubevirt` block holding `migrations` alone,
and the iaas bundle gains only the migrations hop;
- the wiring test takes the four migrations cases and the case for a
null `kubevirt` block, without the assertions that belong to
disabledFeatureGates cases this line does not have;
- `update_idempotency_test.sh` gains `run_update_logged`, a four-line
helper that arrived on main with that work and the new cases need;
- the kubevirt Makefile header counts six sed patches rather than five.

Verified on this branch: 9 kubevirt chart tests, 31 platform wiring
tests (102 across the platform suite), and `update_idempotency_test`
PASS under GNU make and sed. Removing the new awk guard from the
Makefile turns that test red naming the migrations block, so the ported
guard is doing work. On this line `(.Values.kubevirt).migrations` is the
only reader of `.Values.kubevirt`; rewriting it as
`.Values.kubevirt.migrations` turns the null-block case red with a nil
pointer.

Feature summary, unchanged from #4254: cluster-wide migration settings
could only be applied by patching the KubeVirt CR, because the kubevirt
chart did not render `migrations` and the platform bundle did not
forward it. `kubevirt.migrations` now passes through the generated
Package to `spec.configuration.migrations`. A hand patch of that Package
is undone on the next platform render, so this hop is the only supported
setter.

```yaml
kubevirt:
  migrations:
    bandwidthPerMigration: 625M
    parallelMigrationsPerCluster: 2
    parallelOutboundMigrationsPerNode: 1
```

### Screenshots

Not a UI change.

### Downstream repositories

Walked the trigger map against the diff: platform values, the iaas
bundle and the kubevirt chart. The v1.6 reference page of the platform
values had no `kubevirt` section, so the row goes there as a follow-up
that should land with this backport.

- [ ] No downstream repository is affected by this change
- [x] [cozystack/website](https://github.com/cozystack/website) -
follow-up: cozystack/website#705

### Release note

```release-note
feat(kubevirt): expose `kubevirt.migrations` in the platform values and forward it to `spec.configuration.migrations` on the KubeVirt CR, so live-migration bandwidth and parallelism can be set without patching a Package that the platform re-renders.
```

The audit started from labels and dropped every backport PR whose
original was not a candidate for the branch. On release-1.6 that hid
nine hand backports of unlabelled main PRs (#4431 to #4435, #4437,
#4438, #4456 and #4475), and it had no way to notice two open backport
PRs for the same originals: #4421 sat open next to #4456 for #3938 and
#4280, and nothing reported it.

Read the PRs on the branch from the side of the originals they claim as
well, and report two more sections per branch.

UNLABELLED lists each original claimed by backport PRs on the branch
that is not a candidate for it, with every backport PR claiming it and
its state, and says whether they backported it, only claim it with a PR
still open, or were all closed. It never moves the exit code: the gate
answers whether everything labelled landed, and an unlabelled backport
can only add to a branch, never leave a labelled change off it.

DUPLICATE lists each original claimed by two open backport PRs, or by
an open one after another already merged, labelled or not. Both make
the audit exit 1. One of the PRs is redundant, or the open one is the
rest of a split backport; either way someone has to decide before the
cut, and no verdict can say so, since a verdict settles on the first
merged backport or reports the first open one as pending. A closed PR
next to an open one is how a conflicting bot backport gets redone by
hand and is not flagged.

The titles of originals that no listing carries come from one GraphQL
request for the whole run. A failed lookup costs the titles and nothing
else: the URL is derived locally and the exit code is already settled.

--json now emits an object per branch holding candidates, unlabelled
and duplicates arrays, in place of the bare array of verdicts.

On release-1.6 today this lists 13 unlabelled originals, the nine above
among them, and three duplicates that are open right now: the bot's
conflict drafts for #3936, #4254 and #4292 were left open next to their
hand backports, and #4254 and #4292 each also have a fork PR open next
to its reopening from a branch in this repository. #4421 is closed and
shows up only as a closed claim on #4280.

Assisted-by: LLM
Signed-off-by: Myasnikov Daniil <[email protected]>

A candidate counted as backported as soon as its backport PR had merged,
or as soon as any one of its commits showed up on the branch by subject
or -x reference. That is exactly the shape of the backport bot's
conflict drafts: they stop at the first commit that does not apply and
drop the rest, so merging one reads as a finished backport. A two-commit
PR with only its first commit on the branch and no backport PR linked
reported clean and exited 0.

Judge delivery per commit. Every commit the PR contributed has to be on
the branch -- reachable, named by an -x reference, or present under its
own subject -- skipping merge commits and commits that change nothing,
which the bot drops as well (merge_commits: skip; an empty cherry-pick
applies nothing). Nothing weaker counts: not an -x reference to the
PR's merge commit, which survives a cherry-pick later amended to drop a
commit, and not matching lines, which an unrelated line of the same
text satisfies. Subjects are matched one to one, so two commits both
called "fix tests" need two branch commits of that name, and a branch
commit whose -x reference names another commit is evidence only through
that reference. A wrong "backported" is the one answer a release gate
must not give, while a false alarm costs a look.

Some commits carried is partial, listing the missing ones, whatever the
linked backport PR says. A merged backport PR settles a PR of one commit
alone, as before; for a PR of several with none of them found it proves
only that something merged, and the candidate is unverified. Both fail
the gate.

Backports squashed by hand would then keep a branch red for good, so a
maintainer who has checked one can attest it on the merged backport PR
with a comment that is "backport-audit: complete" and nothing else.
That lifts partial or unverified to confirmed, which passes; the report
names who and links the comment. It counts only as the whole comment,
so it needs no reading of markdown: any other text -- a sentence
mentioning it, a quote, a code block, an explanation -- and it is not an
attestation. It counts only on a PR that merged, only from an author
GitHub associates with the repository as OWNER, MEMBER or COLLABORATOR,
and never from automation, whether its login ends in [bot] or is a
review or dependency bot gh reports without the suffix. A review bot
quoting the marker, a maintainer writing "do not post backport-audit:
complete yet", or a contributor vouching for their own backport
confirms nothing. The audit never infers it.

A git read a verdict depends on that fails, a merge commit missing from
the local repository for instance, now stops the audit with exit 2
instead of being read as a PR with no commits to check.

Unlabelled originals are never checked commit by commit, so their merged
claims read "backport PR merged" rather than "backported here".

On release-1.6 this reports five partials. #3955 and #3968 are real
gaps: a labeler mapping and a comment fix never reached the branch.
#4254 and #4292 were squashed by hand and their remaining changes are on
the branch; #3936's backport cherry-picked the PR's merge commit. Those
three are what an attestation is for, once someone has checked them.

Assisted-by: LLM
Signed-off-by: Myasnikov Daniil <[email protected]>