operator: allow custom calico-node run/lib hostPaths for microk8s migration

[locker95]

Description

Manifest→operator migration fails on microk8s (and similar snap-based installs) with:

missing expected volume 'var-run-calico' with hostPath '/var/run/calico'

even though the volume exists under a snap-prefixed path such as
/var/snap/microk8s/current/var/run/calico (and likewise for var-lib-calico).

This PR:

• adds Installation.spec.calicoNodeRunPath and calicoNodeLibPath (defaults remain /var/run/calico and /var/lib/calico);
• during migration, accepts hostPaths equal to the default or ending with that default suffix, and records non-default paths on the Installation;
• renders calico-node hostPath volumes from those fields so post-migration pods keep using the existing paths.

Addresses projectcalico/calico#10733

Release Note

Installation can configure calico-node host paths (calicoNodeRunPath / calicoNodeLibPath); manifest migration accepts microk8s-style snap paths

For PR author

• Tests for change.
• If changing pkg/apis/, run make gen-files (CRD YAML updated for the new Installation fields; string fields need no deepcopy changes)
• If changing versions, run make gen-versions

For PR reviewers

A note for code reviewers - all pull requests must have the following:

• Milestone set according to targeted release.
• Appropriate labels:
  • kind/bug if this is a bug fix.
  • kind/enhancement if this is a a new feature.
  • enterprise if this PR applies to Calico Enterprise only.

[davepgreene]

There are a few other hostpaths in addition to var-run-calico and var-lib-calico that should be made configurable:

• lib-modules
• xtables-lock
• The CNI logging dir (mounted as cni-log-dir)

[caseydavenport]

/sem-approve

[locker95]

Thanks for the review feedback — addressed in the latest push:

@caseydavenport

• Renamed calicoNodeRunPath / calicoNodeLibPath → calicoRunHostPath / calicoLibHostPath as suggested
• Added +kubebuilder:default markers and matching OpenAPI default values in the CRD

@davepgreene

• Agreed lib-modules, xtables-lock, and cni-log-dir are worth making configurable too. Happy to follow up in a subsequent PR (or extend this one if you prefer) once this naming/defaulting pattern looks good.

Locally pkg/controller/migration/convert and pkg/render unit tests pass after the rename.

[davepgreene]

@davepgreene

• Agreed lib-modules, xtables-lock, and cni-log-dir are worth making configurable too. Happy to follow up in a subsequent PR (or extend this one if you prefer) once this naming/defaulting pattern looks good.

imo probably worth adding it to this PR to capture the broad intent of "the operator should create resources that don't require host resources to be in specific paths."

[caseydavenport]

Let's keep the PRs small for now, we can do those in a follow on. Assuming CI passes here, I'm good to merge this one!

[davepgreene]

For reference on follow-ups, microk8s's daemonset volumes are defined here: https://github.com/canonical/microk8s/blob/master/upgrade-scripts/000-switch-to-calico/resources/calico.yaml#L6367-L6416.

Super happy to see this getting merged! 👍

[locker95]

@caseydavenport @davepgreene Thanks for the approval and the microk8s volume references.

Agreed on keeping this PR small. I'll open a follow-up for lib-modules, xtables-lock, and cni-log-dir configurability once this lands.

[caseydavenport]

/sem-approve

[marvin-tigera]

Removing "merge-when-ready" label due to new commits

[caseydavenport]

/sem-approve

[caseydavenport]

/sem-approve

[marvin-tigera]

Removing "merge-when-ready" label due to new commits

[caseydavenport]

/sem-approve

[caseydavenport]

(note: I need to sem-approve each new commit, so just let me know if you need to retrigger CI and I can do it manually!)

[locker95]

@caseydavenport thanks — Semaphore is red again after the last re-run (looks environmental / 3 tests). I'd rather not push another empty commit if that just burns another sem-approve.

If you have a minute to re-trigger CI from your side when you're around, that'd be great.

[caseydavenport]

@locker95 those failures seem to be consistent across all commits in this PR, so I don't think they're flakes - likely real issues. Do they repro running "make ut" locally?